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Abstract 

The  loea  of  relational  mooels  for  oata  bases  can 
be  extendeo  in  a  stralgntf or ord  way  to  yield  a  fairly 
simple  scheme  for  natural  language  access  that  can  be 
easily  tailored  to  any  particular  target  data  base  of 
formatted  records.  A  maior  part  of  this  scheme, 
including  a  processor  tor  queries  in  English,  has  been 
implemented  in  FOPTHAM  on  a  DEC  PDP-li/70  as  a 
demonstration  question-answering  system  witn  Soviet 
aircraft  data,  the  demonstration  system  suggests  a 
design  for  a  low-cost  highly  portable  natural  language 
access  facility  Immediately  applicable  to  existing 
Intelligence  data  oases,  eltner  singly  or  several  at 
the  same  time. 
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EVALUATION 


The  objective  of  this  R&D  effort  consists  in  designing  a  next  generation 
query  facility  that  will  supply  deficiencies  of  information  systems 
within  the  current  SOTA,  such  as  the  requirement  for  special  training 
and  considerable  experience;  arbitrary  and  tedious  access  protocols; 
applicability  to  only  one  target  database  and  requirement  for 
knowledge  of  database  structure/content;  incompatibility  with  other 
information  systems,  and  poor  adaptability  to  new  user  needs. 

The  AQT  approach  offers  the  advantage  of  natural  language  access  by 
non-expert  computer  users  to  differently  formatted  target  databases.  This 
design  feature  eliminates  the  requirement  tor  special  training,  minimizes 
the  dependence  on  one  particular  target  database,  and  cancels  the 
requirement  for  knowledge  of  database  structure/content.  Furthermore, 
the  AQT  approach  imposes  no  restriction  on  access  paths  and  provides 
a  uniform  access  protocol  for  different  target  databases. 


The  AQT  approach  also  provides  portable  technology  applicable  to 
medium  scale  architecture.  The  present  testbed  version  is 
ii:iplemented  in  FORTRAN  on  a  DEC  POP  11/70  under  R3X  11/D,  with 
restrictions  minimizing  dependence  on  this  particular  hardware/OS 
configuration.  A  fully  operational  advanced  query  facility  will  be 
compatible  with  Standard  Software  Base  (SSB)  including  SARP  data 
management  system. 


The  subject  effort  has  provided  a  valid  design  for  a  low  cost,  highly 
portable  query  facility  with  natural  language  access  to  the  existing 
intelligence  databases  regardless  of  their  formatting  features. 

The  facility  will  be  capable  of  accessing  either  a  single  database, 
or  several  databases  at  the  same  time.  The  current  follow-on  effort 
consists  in  development  of  a  prototype  for  hands-on  experimentation; 
research  into  user  needs  and  query  language  requirements;  on-site 
or  off-site  application  of  the  prototype  to  different  intelligence 
databases  on  trial  basis,  and  continuing  evolution  of  the  query 
facility  through  user  feedback,  ultimately  leading  to  a  general 
u  t  i  1  i  ty . 
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SKCTTOn  I 
Introduction 


1.1  un-line  Information  systems  for  intellluence 

Intellloence  analysis  is  oasically  a  process  of  sifting  out 
and  piecing  togetner  data  so  as  to  produce  Information  pertinent 
to  declsion-maiclnq.  xnere  uncooperative  suojects  are  involved, 
tnis  i»ill  seldom  be  as  straiqntf  or  war  a  as  looiclng  at  a  single 
message,  photograpn  or  other  collected  data  item.  more 
typically,  an  analyst  will  nave  to  wor<  inferential ly  from  many 
Incomplete  ana  possibly  even  conflicting  data  items.  In  such  a 
situation,  it  would  seem  oesirable  to  have  as  mucn  data  as 
possiole,  but  in  practice,  tne  ability  to  collect  data  tar 
outstrips  tne  aolllty  of  any  unsupported  analyst  to  ma<e  sense  of 
the  data.  Accordingly,  many  types  of  online  information  systems 
have  peen  developed  to  allow  computers  to  nelp  in  tne  management 
of  larae  files  of  intelligence  data. 

With  mass  storage  devices  ano  control  processing  units 
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Introauction 

contlnul»"o  to  iTorove  in  speea  ar.o  capacity  anile  declining  In 
cost,  tne  tecnnlcal  and  economic  teasibility  ot  online 
intormatior  s/stexs  no  longer  are  In  douot.  laXing  this 
inforTatlor  accessiole  uy  users  witn  actual  need  of  it,  however, 
remains  a  t  roole™  oecause  these  users  typically  lac)c  training  as 
computer  rroaranmers.  Sinply  navlng  data  stored  on  line  does 
automat  leal ly  insure  tnat  it  can  oe  used  effectively.  If  fact, 
there  is  often  a  proolem  j(lth  too  mocn  data  if  access  to  it  is 
gained  only  through  learning  many  different  access  procedures. 

fts  a  neans  ot  making  online  information  more  conveniently 
availatle  to  non-expert  computer  users,  two  key  concepts  have 
emerged  as  iidior  areas  of  ongoing  research  and  development;  the 
relational  iTiO-ielino  of  data  bases  and  allowing  requests  for 
Intormatior  to  ne  expressed  in  a  natural  language  liice  English, 
o  The  teennique  of  relational  modeling  allows  an 
irformatlon  user  to  aoproacn  a  data  base  in  terms 
ot  the  semantic  dependence  oetween  data  items 
•witnout  cons laeration  ot  now  tnls  Is  actually 
implemented  in  tne  aata  base.  Tne  user  sees  data 
as  a  set  of  aostract  relations  defined  over 
prinltlve  data  types;  for  example,  tne  relation 


KfM.titfc-t;  holding  for  tne  aata  types  nA’^E,  lil», 

JLP  CATE'IOPY,  and  AGE,  typically  written  out  as 
f  f  H.(jYEE(  <AmK,  II5*  ,  JUB  CATtGUKY,  AGE) .  The  user  is 
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tais  TkCt  IS  **ST  4Uii-iTi 

.y  '  t’ '■ 


t'AOK  l-i 


cii]c*‘>''-  CO  '-.'joiooidCt;  cf'^  VHrnu3  Itef^iS  ot  o-jCd 
dcCueHv  -isboci-ice'i  aich  i  jlven  rdl-ition  iitnout 
raviTii  to  KiiOA  s  jcfi  ter-i'uC'ii  oet^ils  ds  toe 
rlysic-i’.  ipvice  or^  amci'  arp  store  i,  toe 

lOJlc  -il  or  :doiz-it  ion  ot  stor^je  or,  trie  oevice,  dno 
tre  dccess  -.etnor.  for  letcio':;  to  tri®  i-itd.  AIJ  ot 
tt  is  Aonl'i  oe  o-jiniPo  oy  svste'',  sottAdre  ^ni  T,^'ie 
ti  arsiJ'ire.nt  to  o  user. 

o  /  rer.urol  ioncuo  ie  cauorriiitv  Ioas  ftn  inforr  jtlon 
user  to  refer  to  trie  contents  ot  ^  nata  oise  in  trie 
Sore  Adv  tone  d  i-'erson  a,-),j1o  tii<  dorjut  fien  in  a 
idr.i.un  le  Hkp  Knilisn.  ir.is  ones  fjrtner  trtnn  siriniy 
jrclijoifu!  tnuisn  <evior<)S  in  o  torril  OJerv  Janoaeae 
or  r.avim  tn®  syntax  ot  triat  lamjaoe  i.njtace  tne  tort, 

01  tnjiisn  sentences;  naturalness  i'lsiies  trist  a 
rersc.i  cm  also  use  tne  various  taTiiiar  senantic  con- 
ver.tlons  ot  a  lanoui-je  liKe  rnoiisn  to  oescrioe  c'le 
various  Kin  is  of  looic  il  oei-en.-.ence  Alt.nin  a  oata  oase. 

id  son  snouin  ne  :inie  to  use  a  r,rttural  nuerv  lan>;uaje 
Aiitout  ir-ivin  I  to  n.riOA  rinytr  In;  tore  tnan  tne  aenerai 
fact  Coat  a  oiven  oata  r.ase  contains  certain  xlnOs  ot 
ir  tor  'latlon. 

aniii  relational  r.o,relini  a.no  riatural  lanoLiaoe  uuervino  have 


neen  ipt  lerrepte  i  in  a  *iie  varietv  ot  exoer  mental  systensr  otten 


yltli  t(:t  t^O  IM  CO  i.r  1  Oft 


s'iccess  of  tiiese  systems  in 


SI ’t  1 X  f  v'l  fi<'  Ciic-^  ot5“  dcc<*ss  tot  no-i-exnert  users  nas  stimulated 
luttrer.t,  rut  it  (•'is  uroveu  lifticuxt  to  introouce  tnem  into 
actual  /orriri  environ  nents .  tre  -rooiem  is  t.otn  technical  and 
iT.ar  <1  ler  i ol .  i  n  tne  one  r.nn  i,  s  'ali  ey oer  in  ento  1  systems  tend  to 
scale  uL  l  oorly,  since  tr.ey  teno  to  oo ;  do*'n  cofi.iJUtationally  as 
oata  oases  aitrn-jcn  the  size  of  tncse  tyoically  in  ttie  real 
.*or]n;  tr  t  ne  otner  nano,  infor'iation  systeiii  .nanaxers  are 
reluctart  tn  <o  'it  tiie'.selves  to  a  ne*,  tairiy  comnlex  system 
ti>at  rr-.ev  cat. r  nr  e-tsily  “valuate, 

I'lVX^o  cut  -i  relational  t)r  I'.'itural  lan'^uaoe  ouery  system  can 
oe  costly.  It  "av  involve  ^  nreat  deal  of  special  or odramming  as 
leii  as  rrar.sliticn  of  lata  fro''  existin?  formats  into  formats 
accet-tarlt  to  t' e  system.  irie  ettort  vill  also  be  risky  in  tnat 
mere  is  nc  ouirantee  tnat  tf.e  syste"  »’ill  meet  tne  oerceived 
needs  ct  f-iven  user  or  that  it  xiil  even  run  «itn  a  given  data 
oase.  ir«re  f  iy  aiso  ■>“  fronier.s  or  inteority  li  lUltipie  copies 
of  data  f  ave  to  r-e  "ane  necoiisc-  of  incomoat  in  lity  oet^een  tne 
renui  r  ei' er.t  s  of  oatirai  lanooH-ie  goery  orocessim  ano  existing 
oata  (,  rc  cessir  1  , 


l/.e  /.ovanceo  ;oery  fecnni  aies  («-.>i)  project  *‘>^s  initiated  in 
an  pftrrt  to  s'''Ootn  out  so"e  of  tne  oitticuities  in  getting  the 
tecr.nolcc.y  ct  rei-itionnl  oata  oases  arid  natural  language  to  users 
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in  ne^d  of  convenient  -itiJ  fiexifie  •access  to  online  intelligence 
date  oases.  1 le  qoal  of  tne  project  'as  first  to  identify  a 
sunset  of  sucn  tecnnoloiy  an.-ropr  late  to  iritell  inence  data 
analysis  am  tnen  to  oiin  a  system',  to  oeTonstr  ate  tne 
effectiveness  ot  tnis  tecnnolo^y  to  potential  users  inteilinence. 
lo  acconrlisr  trus#  xe  nave  oeveiooeo  an  extended  xind  of 
relational  oata  none!  aesivineo  specltically  jultn  natural  lanquaqe 
in  mine  are  nave  i.uc lenenceo  a  eemonstration  system  on  a  dtX 
i»DP-il/7o  usin.'j  tne  extended  oata  .looel  as  a  means  ot  translatinq 
natural  lanGuate  queries  Into  references  to  a  taroet  data  oase. 

Some  exanoies  of  queries  nanoieo  oy  tne  t.jT  deifionstrat  ion 
systen : 


rfhat  is  tne  fuseiaqe  ienqtn  of  tne  foxoat? 
t’f  tn.e  floqqer? 

Averaae  ^inqsoan  of  all  nlGsV 
nox  rany  fiooters  or  inter cet cor s  carry  tne 
Atoll  nissilef 
“'fdt  configurations? 

<;Jve  me  cneir  coiioat  raoi  is. 
ineir  gross  *ei3nt. 

I'Mcl.  ot  tnese  nave  i  cre^imen? 


1  creviran? 


introduct ioi 


ITe  recoro  ol  'in  acto^ii  session  <citn  tne  demonstration  system  is 
oiven  ir  a. 

Ire  den  ons  tratlon  syste.'*  is  written  in  FOktrAi  and  currently 
runs  on  eltrer  wSa-M'  or  -ill).  It  Is  set  uo  to  oe  taole-driven 
so  as  to  nate  it  Inoepenoent  oL  any  given  oata  case.  It  will  be 
tne  nosis  tore  for  tre  oesiqn  of  a  full  prototype  portable 
natural  larcnai®  query’  facility  runnanie  on  a  processor  as  small 
as  a  I'tC  I-r;>‘-l  t /AO.  inis  facility  will  maxe  It  posslole  for 
practlcalU  ary  user  to  nave  natural  language  access  to  existing 
format  te  l  oata  oases  *itn  no  additional  naroware  and  witn  no 
additional  sort*are  exceot  possiolv  for  special  routines  to 
ranole  unusual  uata  t/pes  or  llnitages. 


1.x  oacKorour.d 

rtort  or  AvX  ceoan  as  an  outorowtn  of  an  evaluation  of  tbe 
hfcii  iRaridJv  nxterisible  Lanouagei  system  lioj  t>y  par  Corporation 
for  RAf'C  (contract  »K iuo0ii-75-o241 ) .  Although  HUL  was  and  still 
IS  a  rro'i'islrc  natural  language  oata  analysis  system,  we  found  it 
most  interestim  m  the  areas  of  turtner  research  that  it 
suggested.  une  narticulariy  striting  proolem  was  tnat  of  now  to 
name  the  nirary  relational  oata  structures  employed  by  REL  so  as 


to  mare  tier  as  transparent  as  possible  to  a  user.  The  REL 
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iystem  never  nirectiy  aoijressel  tnis  issue  otMer  than  to  orovide 
a  way  for  iisers  to  aetine  local  synonyms  for  existin'?  names. 

In  a  hroaaer  context,  the  nan.in?  problem  turns  out  to  oe 
only  ore  asrect  ot  a  more  oeneral  oitficulty  that  relational  data 
systeiis  tenc.  to  qioss  over.  It  is  often  implleo  tnat  a  standard 
relational  rerresentation  ot  oata  sucn  as  tni rd-norir.al  form  is  in 
some  sense  natural  and  tnat  its  oroaaization  ano  labelind  should 
therefore  ne  oovious  to  any  user.  Inis  is  not  necessarily  so, 
however;  ter  is  -ve  snail  snow,  there  are  many  different  possible 
realizatlotf  for  a  oiven  item  of  oata  in  a  oiven  canonical  form 
of  relational  representation.  To  maxe  the  oroanization  of  a 
relational  oata  oase  completely  transparent  to  a  user,  we  have  to 
make  tre  croice  of  relational  structures  transparent  as  well. 

To  attack  this  problem,  we  started  by  extending  the  notion 
of  relational  data  structures  to  include  a  hierarcnical  ordering 
of  relatlors  ani  to  alio*  relations  to  innerit  key  fields  from 
further  ui  in  the  nierareny.  nitn  strict  rules  on  tne  naming  of 
relations  ir  this  framexorK,  tne  model  turns  out  to  be  quite 
transparent  to  a  user  ano  in  tact  suggests  now  English  queries 
might  re  interpreted  -Itnin  tne  monel.  Tne  model  is  still 
suttlcientlv  si"ole  in  structure,  however,  tnat  mapping  it  back 
onto  a  target  data  base  can  be  accomplished  through  a 
straighttorw.ard  tanie-oriven  orocedure. 
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Ifie  use  of  Inter. tiedtace  locjical  Dodel  in  natural  lanquaae 
aata  case  access  nas  tne  a-ivantau*  of  solittinq  tne  problem  into 
two  separate  suopron  lems :  nat.jral  lamuage  orocessinq  an.i  oata 
oase  access  orocessinj.  The  natural  lanquaqe  part  unexpecteoly 
turned  out  to  be  tne  easier  one,  larqely  nerause  ot  tne 
availability  of  tne  pakuhZ  («j  system  tor  oevelooinq  query 
lanquaae  qrarrr'ars  and  parsers  .oriven  oy  tnem.  «ie  were  fairly 
quiclcly  able  to  oroonce  a  demonstration  on  a  OhC  P()P-ll/70  for 
tne  translation  of  n  siqntflcant  suoset  of  Knqlisn  into  an 
intermealate  query  lanouaTe  oirecteq  at  a  oiven  relational 
nlerarchy  servinq  as  a  loolcal  data  moael,  rianoling  tarqet  data 
base  access  tnoK  a  great  deal  more  time. 

At  first,  our  Plan  >ias  to  use  existinj  soft*are  from  tne 
SAKP  rifcj  data  manaoement  facility  to  handle  data  base 
activities,  since  this  would  reduce  tne  amount  of  prooramminq 
required  to  oring  up  an  Avf  demonstrate  system.  Delays  in  tne 
delivery  ot  SAiIP  ana  ina’aeduate  documentation,  no>ever,  forced  a 
cnanqe  ot  course.  Given  the  imoeratlve  ot  snowino  tne 
effectiveness  ot  ADl,  *e  decided  to  put  SAKp  aslae  temporarily 
and  to  brinq  uo  a  simple  data  base  ourselves  on  a  P.3P  H//0,  To 
avola  .Deinq  unrealistic,  <re  oiaced  no  prior  conditions  on  tne 
organization  ot  tne  oata  base  and  designed  tne  data  access  part 
ot  tne  detiiopstration  system  to  avoid  any  assumotlons  about  the 
structure  ot  tne  tarqet  data  oase.  rnis  in  eftect  made  tne 
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I’AoK  I-*! 


dPTionst ratior  svsteii  into  a  orell^iinary  version  ot  a  tuil  Ayl 

tacilltv. 

Iri  trls  c-ioaclty,  tf»c  oenonstratiofi  systen  was  a  valaaole 
tPStoen  tor  j-veiooinn  tecnnnnes  for  sneclfyinj  nata  oase 
structure  In  taole  torrc,  jenerating  oata  access  oaths, 
controllino  njta  oase  searcnes,  resolvim  ueries  -lenenoent  in 
rneanlno  on  a  crecellni  juery,  selectino  ann  tornattim  output, 
and  roru-utiti  i  various  statistical  f  jnctions  ot  oata.  Tne 
oeniorstrat  irn  syste..  ny  runnirvj  on  a  koy-ll/lO  also  sho*s  tne 
teaslMlity  ot  iroia''.er.tinn  an  Ao  I  tacility  even  on  Tieilui'-scale 
i.iacMne  arcr itecture. 


J ,3  other  ai i ro  icnes 

Prooronirlni  a  nacnln<»  to  unierstana  natural  lan-juaoe  is 
always  trorn-ously  '^ore  ciitficult  tnan  irost  people  expect.  It  *as 
soon  alter  tre  construction  ot  tne  tlrst  electronic  computer,  tor 
exan.ple,  tt.at  the  first  proposals  tor  automatic  translation  of 
Idreion  larouajes  ♦'ere  idoe,  at  tne  time,  tnls  seemed  to  ne 
witriin  read'  ot  tne  urjpreceaentea  co  noutational  power  oecominu 
rtvailaole;  o  it  raw  power  cy  itself  turned  out  to  ne 
Ihsuttlcier.t ,  wltn  steady  tecnnolo  iicai  orouress,  tnere  are  now 


laroer  -ano  taster  Processors 


more  sopnlsticateo  proiranminp 


lat  rO'Tuct  Icn 


I'lriuuooes  i’r.n  i.et'ioooio  lies,  -5  oeener  trieoreticdl  qresp  ot 

natuT'^l  lor. Cl. tie;  r'jt  even  tr.ese  nove  faileo  to  brlrifi  aoout  tne 
"toltcln'i  ccntoter"  ot  popular  •■•vtn. 

hcjor  Tiftic'ilty  in  ojiiaino  natjrai  language  systems  is 
in  li'ifiri-i  tn-!  .ronie-  to  ^  It  nianaoeanl  e .  Tn  numan  beings, 
lincruistir  fe.'iivior  Is  closely  inter twinen  *itn  Intellectual, 
e.Tot  ior:til ,  an  1  social  -lenauior  so  tnat  anv  attemnt  emulate  human 
lliiauistic  lehivior  soon  rets  into  co'm  1  icat ions .  Tne  nroolem  ot 
nettir.u  coitputers  to  reao  sin.v.ie  stories  illustrates  tne  point 
here;  mere  is  not  only  a  tre-'^enoous ly  rich  array  ot  language  to 
be  oealt  ^'Itn  some’io*,  nut  also  the  formioaole  tasi<'  ot 
Incorroratir c  a  nroan  supoortive  repertory  ot  linguistic  and 
non-1  inoii  1  f  t  i c  henavior  in  a  system  oecause  any  real 
i.inoer  stanoirn  or  i  story  reuuires  oeiog  aole  to  make  an 
appropriate  response  to  it. 

Ill  rr.is  context  of  the  natural  lanouaoe  nroDlem,  we  can 
oist  Inoi' 1  S(i  t'.’o  nasic  aporoacoes  to  ruilding  systems.  The  first 
is  trie  lonystaml n  1  "taiiting  comouter”  approach  t.hat  envisions 
'^aKino  con. Viters  full  :,>artners  of  human  ceims  by  ultimately 
oivirm  trie.T  tne  pokier  i>t.  speern.  Tne  tocus  here  is  typically  on 
attacking  oitfic.iit  pronlens  irf  natural  language  understanding 
wilh  the  coal  of  ceveioPlnu  ne*  techniques  for  nandllno  them, 
.systems  luiit  aloni  tiiese  lines  are  otten  highly  successful  Cc.f. 
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Mino^rsfi’ s  system  li4j>,  out  tne  (reasure  ot  success  tor 
such  a  systeT  tenos  to  niinlv  correlated  vultn  the  nua.oer  of  ne* 
difficult  proMems  tfiat  it  opens  uo. 

Ar  altoqecner  different  vay  to  ojilo  natural  languade 
systems  is  »rnt  *e  ir.iont  Call  tne  "nuts  and  noits"  aporoacn. 
Insteao  of  attempting  to  come  up  .litn  malor  drea<tnro ughs ,  *ie  can 
taice  the  olde  range  of  language  processing  tecnnioues  availaole 
and  try  to  tit  tnem  togetner  in  orner  to  solve  a  practical 
proolem.  In  tne  last  several,  this  aroroacn  nas  necome 
especially  rroninent  i«itn  an  orientation  toward  itiuroving  tne 
accessibility  of  information  storei  in  on-line  comouter  data 
oases.  A  query  facility  cased  on  Ayl  falls  into  tnis  category, 
and  so  to  put  it  Into  perspective,  *e  need  to  Iook  at  tne  other 
systems  around. 


i.d.l 


l.i.i.l 


rne  KtL  system  nas  oeen  mentloneo  alreaoy  tl^J.  Inis  is  a 
relational  data  analysis  system  *ltn  an  tngiisn  query  interface 
mat  is  readily  extendable  ny  a  user  *nlle  at  a  terminal.  The 
extensions  are  mostly  lixe  macro  uetlnitions,  serving  to  expano  a 
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particular  user's  *ay  of  s=»yin'3  things  into  conceots  and 
ooeratlcrs  dlreany  Knonn  to  tne  system..  Tnese  Kinds  of  extension 
woulo  ailov  a  user  eventually  to  tailor  a  ouery  ianauage  to  oe 
•naxi'cally  convenient  for  a  given  application. 

Kf.L  was  originally  impie '’ented  on  an  3no/bb  in  assemoly 
lanoiiat.e  tor  sneen  mu  coapactr>ess .  Current  versions  are  oeing 
alrecten  toward  otner  nacnines*  incluolnq  one  soeclal-purpose 
Ttinicor.  ^  uter  ouilt  to  run  nnL.  Tne  system  is  desi  ineo  for  I/O 
efficiency,  rel/inu  on  aata  oeinn  storeo  in  a  special  binary 
relational  tormat  ano  on  direct  onyslcai  access  to  secondary 
storage,  posslnlv  uavlni  to  go  arouni  tne  tile  s/steTi  management 
for  a  processor.  i.anouaue  orocessinq  is  done  tnrougn  a 
syntax-rr  1  vrn  scnete,  uslnu  a  uarser  designed  to  nanole  tne  most 
ueneraJ  rev  rite  gram•?^a^s. 

un  t!.e  wr.ole,  apnears  to  worx  nut  as  a  practical  system 
alr.ed  at  nala  analysis  as  carried  out  in  tne  real  -vorld.  Actual 
non-exrert  users  see-n  able  to  apply  tne  ^El  definitional  facility 
in  et»fct  to  '‘rite  data  processlm  programs  in  English.  Tne 
maior  snortcomino  of  ^KL  is  pronably  its  restrictive  data 
fortattlro  reguirements ;  data  physically  has  to  be  stored  in  a 
soeciflc  *ay  before  I'Ki,  car.  nor^r  jvitn  it.  This  also  leads  to 
dltflculties  ufhere  fairTy  complex  data  is  involved;  althouoh 
binary  relatiois  are  theoretically  sufficient  to  represent  any 
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kind  ot  orita  str;)Ctijr ,  it  is  not  clp^r  tn<it  tnp  Hr,u  lanouage 
processlr.o  caodhillty  can  natce  arnitranily  coinospo  ninarv 
relations  easily  accesslnle  to  a  user.  Finally,  tnere  is  a 
prorieiT  vittn  tne  ninlng  ot  relitions  and  tiei-is  tnat  prevents  tne 
SYstedi  fror  oeino  fiiiiy  transparent  (see  Section  2.1,). 


1 . 3.  1 .2 

Pi'HHT  (bJ  is  a  CO  n.nercial  ly  avaliaole  svste"i  intended 
prltiarily  tor  T'andjenent  information  aupl  icatlons.  Its  oasic 
idea  Is  sinrle,  nut  effective  -  namely  tnat  a  oata  nase  itself 
can  oe  used  as  an  extension  of  a  dictionary,  practically 
ellminatino  any  need  for  a  separate  vorld  node!  to  duide  lanqoaae 
analysis.  In  nractice,  tnis  Involves  folly  inverting  a  data  nase 
to  get  index  lists  of  tne  records  containing  a  given  value  in  a 
given  fiela.  tne  systeit  is  designed  to  taxe  aovantaae  of  tne 
Index  lists  w),erever  ros^iole  In  uata  base  searcn,  reaucino  tne 
neea  to  rear  In  target  data  rase  records. 

Cnrrertly,  dijijT  is  sntf Iciently  well  estaolisned  to  nave  an 
organizec  users  group.  Non-technical  manaoers  and  tneir  staffs 
aorear  to  tiro  tne  system,  easy  to  *orx  vltn  ang  tne  information 
returnee  ty  tne  system  usernl.  J  lie  system  is  fairly  modest, 
runnlno  on  an  ta»  37)/ibs  •Itti  lOOn  to  200K  rytes  of  nemory.  The 
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nrjtoral  l^^roiMip  nrocessiri'j  Is  none  *ith  fln  di)TH'ente>'i  transition 
net  fA'Jt  )  fprsi.!!  scne^c  (ISJ. 

It  Is  LPrlesr  vet  ho*  coT.oiex  a  oata  case  huhht  can  handle 
eftectivlpv.  I'oe  nronlen  is  tne  requirement  to  full  inversion, 
fthicn  nav  rot  nl*'o,'s  oo  reasonaole  to  do.  tne  r(i)Hi}T  system  at 
(’resent  seers  restricted  to  extremeW  simple  data  file 
oroanirat lor s ,  rostiv  linear  tiles  of  records  tnat  would 
typically  te  searched  vlto  a  sequential  access  metnod.  This  is 
procaolv  acecunte  for  some  ouslness  applications,  out  it  may  be 
too  slrplistlc  tor  a  hioniy  structureo  S&T  data  base. 


1 . 3 . 1 . 1 


Planes  is  a  ouery  taclllity  tnat  translate  natural  lanouaqe 
queries  into  forral  queries  directed  at  a  relational  data  base 
Contairirq  naintenance  inforrmtion  anout  naval  aircraft.  It 
taKes  aovanta  le  of  tne  restriction  of  its  domain  of  discourse  to 
sl'noiifv  tre  overall  problem  of  natural  languaie  nrocessing.  Tne 
system  ains  not  at  emulatlno  nunan  idnjuaoe  comorenenslon ,  but  at 
encjineerino  a  cractical  system  for  a  particular  Information 
nror ipM  . 


ire  system  is  designed  to  be  tolerant  about  tne  form  of 


1 ntroTuct 1  on 


1-is 


■.tuerics.  It  .ivji  ;s  striCL  :r  tt  ■  rjt;  i  1  nos  3  t-v  .ism;  ^ 

iocdl  r-Hrsir-'i  sciic  I  uso  I  rin  i  tr  <  iS)tiori  :iPis  to  Jet  a 


set 

of 

rr  rases  fro  a  :i 

iCT  . 

,•  aO  ‘  t  lO'l  • 

1  j  i  vj  ccnc^.j 

t  ja 1  case  fra  res 

1 0 

tie 

treso  t'lintner. 

r  t 

»  1  S  f  K,  p  a  "  S 

rlosi'  tt'irK 

nf  tne  cnntexr 

of 

'.ttmrits  so  ts  to 

•t.'lO  t'  fll 

11  t  -1 

I'Hrts 

1  0 1  C  1  n  c  0  :  0  1  e  t  e  . 

I'ne 

lar. 

cuir^'.e  :  roc^ss  1 

Co 

'  i"  >  1  1  r  0  t 

H  0  -V 

0*1 

r  r.  e  /note  is 

tairlv  '  n  t  ►  j  b  t  f".'!  t  o  !  rn  r''o  tfr  it. 

At  rrtpnr.c#  1  <;  >iot  t,>j-  .lovori'-*  an 

aircraft  r  a  i  ?it.of>M',co  loti  nise,  .jitv')i;'i  its  nse  nt  1  re  1  at  ioita  1 
oato  iriTPiti.ce  ano<s  lat.-.  r-ise  irne  '"’' ience  to  sn-.e  extent.  ine 
SYStei'i  srf  ci  t.  ic  i  1  1 V  lerntros  oil  jat  <  to  im*  store.)  in  a 
non-i.ie  r  arc‘ 1C  ti  tanuiar  tofar.,  no^ever.  .r~  is  i  nn  i  e  rent  e-J 

on  a  (/(■(■  .SiStm  I"  in 

1.3.1 


l  »  i  i‘-'l  l*  j  is  j  ■‘•to  >  iSe  iccess  .svste  i  '  tin  a 

natiTdl  larou-^*ie  I'ltertice  -otin-'-i  -  itn  soecial  iiaturai 

iar.'jiiaon  rrocnssini  s'lt-’.air r  .  -iC<s-*».  t'ip  svste'  co>'.sists  of 
tiiree  rnjor  rn-i  n^|^'r'.♦  s :  a  ■.  .prv  ■••'■cerror  t'^t  oro  juces  torr.at 

rrrrievei  snt  C  t  f  IC  at  ions  irn  Ojt.'ral  lai’ija'n  iinut,  a 

translator  tt  it  -ronif^s  1  .  ^  'Ivan  tariet  :at  >  n-ise 

oaiaonrnnt  svst"'  icr^ss  'anj-.i..'  fr*  s.iec  1 1  teat  tons,  ann  an 
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access  rsfifscpr  tjn'is  loc-ition  of  ril“s  referenced  oy 

ii'ienes  nrn  coes  .,11  t'i»-  lecess-^rv  oroce^jr<»s  tor  'jettinrj 

.iccfs?  to  irei,  >'iles  i;'’.  i  toroet  Ufa  n-ase  ■' ly  :>e  scattered 
across  s'ver.'l  liftcren'-  co'<'i;  iter  syster^s  lirKe^j  Into  a  netviorlc. 

r.itor-ii  n-rvj.iic  lotertace  IS  desioneo  to  ne  extenlanie 
oy  -1  .;scr  si.^uttini  e<^~iles  of  nea  loery  tores  am  steel  tying 
“Ox  rriey  ^re  to  oo  loteror  eteo  relative  to  recoentze-j  tornis.  Tne 
entir*"  micrtt^c*  In  tart  can  oe  tailorei  interactively  to  a  given 
aiM  iicarior,  r  'ore  ootoi  ro  initial  core  ora’ro.ar  suoolled.  Tne 
onlv  r<  St  r  let  ion  t.o  jetini!,;  a  Tiery  lanonaje  fron  scroten  is 
mat  toe  .'ersoo  s  ■o’ci  f  vi.'i  i  It  nas  oe  oe  taoiliar  ‘itn  tne 
orogra’’ '  1 1  •;  i  iiiiaie,  since  tne  oasic  svsteT  is  InoleTented  in 
I 1 1  H/i  tn  a  .in'  (>1-1  I.  roe  facilities  siitoly  for  netininq  ne* 
rcr^s  an',  ;  artio oresns  ar«  niic  1  easier  to  'ise,  ttiooin. 

l/iiit  is  in  ^eceti  tent  of  a  taroet  oata  case  to  the  extent 
tnat  its  tra.is  liter  ano  access  Tananer  components  can  oe 
r“i  lacec.  i(  rs‘>  "omIps  aopfar  to  contain  taroet  data  deoendent 
code,  aitioior  "ost  ot  t n  1  s  IS  orooaoly  connected  *itn  particular 
oata  Ofise  I  c n,,  i« '.eot  system's  ano  not  altn  tne  contents  ot  a  data 
rase,  1 n e  translator  ■  ocile  esoecially  would  nave  to  ne  cnanoed 
If  tne  tamer  lata  oaso  maiaJp'ieiit  svster  were  chanoed. 
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1.3.2 


The  AtT  anciroacfi  n^s  sorretnlnn  in  co'^  non  *  ltn  earn  of  tne 
systems  nentloned  here,  out  most  closely  resembles  uAtinoK.  Litce 
LaDOKW,  an  AV'i  facility  is  oasei  on  a  "ulti-staqe  translation 
process  that  attemots  to  maice  tne  structure  of  a  taruet  data  base 
transparent  to  a  user  tnrouor;  methods  that  can  oe  applied  to  data 
bases  cf  aifterent  structure  and  content.  /ne  orientation  of 
AQT,  thouor.,  is  sliohtlv  oifcerert  in  its  eirpioyment  of  a  (cind  of 
relational  data  model  and  a  oasic  nuery  lanouaue  ara.nTar,  brim 
It  closer  in  tnis  rescect  to  kki,  and  flau^.s. 

As  natural  lanouaqe  systems,  ail  four  of  the  systems  nere  as 
•Hell  as  Ai'T  appear  to  aim  at  aoout  tne  same  practical  level  of 
competence,  adequate  tor  tneir  intended  use  *itn  data  oases  out 
not  srectacii i ar .  Aithouah  the  tec/.nJoues  vary,  an  tne  systems 
seem  to  aoree  on  the  importance  of  r-roolems  liice  ejiipsis  and 
simple  reference,  ‘-.here  tne  other  systems  oiveroe  most  from  A.2r 
Is  In  tne  conception  of  an  AOT  facility  as  a  small,  iow-risn 
system  runninj  vitn  limited  resources  in  a  user's  ooeratim 
environment;  tnis  is  reflected  in  t^\e  implementation  of  the  AQl 
demonstration  svstem  in  kiiFTKA''  on  a  OKC  Pr'P-ll/70. 
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Concents 


/.I  f^xter'oirc  relational  o-jta  noiels 

rre  central  concent  underlying  tne  AOT  facility  Is  an 
extension  ot  tne  notion  of  relational  gata  structures  [2], 
rielational  rodels  for  data  oases  i'norove  a  great  deal  on 
classical  nptroacnes  oy  maXim  access  nf.ethods  and  data  record 
organization  transparent  to  a  user;  nut  tney  still  require  tne 
user  to  krow  something  aoout  tne  structure  of  a  data  base.  Tne 
pronler  is  tnat  tnere  is  no  one  natural  way  to  exoress  any  given 
oata  in  terrs  of  relations.  For  example,  data  about  the 
nardenlng  ot  support  airfields  against  airstriK.es  might 
conceivanlv  ne  organized  in  many  different  ways: 

piKMfl.i'i  [...,  tvpe=support ,  nard=yes] 


Si:tP(.P'i  AIor'IKMX  .... 


status=nar dened) 
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i...,  class=sup>Jort  alrfielo, 
vulneraoilitv=r''^r'il 


vKhere  relatior  nares  aopear  in  upper  case  to  t.ie  left  of  a  set  of 
oracKets  ano  flelo  naines  an-i  associatec  values  aonear  wltnin 
OracKets,  As  can  be  seen,  wnat  constitutes  relation  names,  field 
nat'-es,  and  value  oesionations  can  oe  r»ionlv  relative;  variations 
in  relational  structures  can  be  nulte  radical,  noinu  tar  beyond 
tne  standard  aln^oraic  ooerations  used  to  uerive  ne»  relations 
from  old  or.es. 

To  aet  at  information  in  a  r**lation  data  base,  a  user  would 
ordinarily  have  to  Know  about  its  oarticular  loalcal 
oroanizatlon ;  tne  actual  names  of  oetined  relations,  the  actual 
names  of  i lei  is  contained  in  eacn  relation,  ana  tne  tvnes  of 
values  associated  witn  eacn  field,  as  well  as  the  uraomatic 
sltTnlf leaner  of  certain  values  beim  associated  *itn  certain 
fields  in  certain  relations.  because  tnese  are  ail  somewhat 


arnltrarv*  however.  tr.ey  are  inessential  to  the  oroblem  of  data 
oase  access,  servlm  only  to  complicate  tne  situation  for  a  given 
user.  If  a  data  case  is  icnovn  to  contain  inf oriration  about  the 
naraenino  of  sujnort  airfielos  aoainst  airstriKes,  tnen  a  user 
ounnt  to  te  able  simniy  to  asK  "Is  airfield  <XX  hardened?" 
witno'jt  rictvir.'j  to  *orry  about  the  various  additional  details 
imposed  rv  a  given  relational  representation. 

The  cifticulty  Aitn  tne  'ianv  different  wavs  that  relations, 
fields  arc  values  niont  oe  defined  for  any  given  data  base  turns 
out  Co  re  a  Key  ciio  to  solvlnu  tne  problem,  tnougn.  If  tne 
variants  of  a  relational  representation  are  viewed  from  a 
llnciulstic  standpoint,  then  we  can  interpret  them  as  the  result 
of  the  various  Kinds  of  syntactic  transformations  familiar  to 
natural  lancua  je  cn.  Tne  straiontf orward  apolication  of  natural 
lanauacf-  analysts  to  relational  nomenclature  can  therefore  -jo  far 
to  iiaKe  relational  data  structures  it.ore  transparent  to  users. 
This  is  ruch  more,  it  snould  be  noted,  than  simply  allowing  the 
duerles  to  a  relatio!>al  data  base  system  to  imitate  Kngllsh 
syntax. 

An  opvlous  startind  noint  for  studying  transformations  and 
data  rase  nomenclature  Is  to  looK  at  now  words  are  combined  to 
forn  the  pares  of  relations  and  fields  in  general.  In  tne 
cofitext  of  a  diven  data  base,  we  tend  to  see  that  certain  label 
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words  (noors)  seem  esDeci<sliy  i  "nort-»r>t .  servini  as  tne  Drlncloal 
•ord  ot  oescriotlve  relation  nanes  or  as  oistlnooisninq 
Qualifiers  In  ootn  relation  am  field  nair.es.  Tnese  are  in  a 
sense  Invariant  under  tne  various  linioistlc  tr ansf ormat ions  on 
relational  cara  structures;  for  exa^mle,  a  transformation  -nav 
involve  removlnj  suc'i  a  laoel  ‘on  from  a  relation  na.ne,  nut  only 
to  put  it  else*fiere,  oernaos  as  a  ne.  noolfier  of  fielu  names  In 
tne  relation. 

msH  4GK  01 'iK'Ki ('.‘■t  l...»  lenutnsxxx,  viotnsyyyj 

necomes 

DlyEfSinu  l,..»  toseiaoe  lenotri  =  xxx, 

fuselaoe  «i-itnsyyyj 


In  natural  lanoua  je  oisco  jrse,  tt,e  Important  laoel  words  for 
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a  oiven  oata  uasa  teno  to  nave  a  oefinite  partial  orOerlno  In 
terrs  ot  *teir  relative  position  In  different  possiole  relation 
ana  tlelii  rar-e-i;  whenever  two  such  label  woris  appear  in  a  name, 
one  almost  alnys  nreceaes  tne  other.  For  example, 

•\ I r'fv At  )  A I i. I 

t' I  to  J 
T  !)T  .’KhS  Ii'  i 
AlPC'^Ar  T  l"(; 


out  not , 


etvG 

(Tnere  is,  to  oe  sure,  a  habit  in  some  orancnes  of  the  military 
to  cor.5tn.ct  noun  nnrases  wit.n  back*aros  nooitication,  but  this 
is  upnarural  witn  resoect  to  common  usaoe.l  The  partial  orderihg 
here  is  sli.rly  a  leneralizatlon  of  patterns  of  speech  ana  yields 
a  natural  hierarchy  of  label  words  for  a  given  data  base.  This 
hierarchy  defines  a  partial  semantic  analysis  of  the  descriptive 
relation  names  for  Che  data  base  -and  thus  also  an  analysis  ot  the 
data  relations  triemselvcs. 

A  hierarchical  cecomposlclon  of  relation  names  provides  the 
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oasis  for  a  simple  extension  of  relational  nata  structures. 
First,  we  will  allow  multiple  occurrences  of  laoel  wor-is  in  a 
Merarcny  so  tnat  It  can  necome  a  tree  (or  a  forest  of  trees).  A 
fiata  relation  now  -Jescr ipt Ively  corresponds  to  a  downward  oatn  of 
label  woros  in  tne  nierarchy.  we  can  reinforce  this 
correspondence  oy  .napolng  over  tne  fielo  names  of  data  relations 
now  as  well,  movinu  them  uo  in  the  nierarchy  until  they  are 

semantically  dependent  on  tne  concept  denoted  oy  a  label  word  at 

some  level.  within  a  relational  nierarchy,  field  names  with  a 
common  label  word  nodlfier  can  re  analyzed  further  oy  creatine;  a 

new  sublevel  for  tnat  label  word  and  moving  tnese  names  less  the 

modifier  down  to  that  sublevel.  Tnis  procedure  results  in  a  new 
set  of  data  relations,  eacn  named  by  a  sinole  laoel  word  and 
having  a  hierarchical  ordering. 

AiK’C(-AfT  (nato  name=xx;:,  ...i 

e 

;  .  .FUSSbAr.n  (...)  ' 

:  :  .  .ur-'t.usiod  Clenqtn^yyv,  ...] 

;  .  .WING  (tyoe=tttt,  ...J 

5  .  .hlMFUsiijr,  (dihedral  andle=zzz) 

This  sort  Of  structure  win  be  called  a  "relational  hierarchy"; 
It  could  be  i>ore  formally  defined  as  a  partially-ordered  set  of 
relational  oata  structures  wltn  slnule-word  labels,  wnere  the 
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nierarcnv  r.  cn-ls  tvpical  nsaae  of  *or-ls  in  simple  F.mllsh  noun 
pnrases  vben  taiicing  arout  a  given  nata  nase. 

1 c  crtain  a  relation  merarcnv  as  a  logical  model  for  a 
alven  tiaca  rase,  *e  first  net  a  standard  relational  model  for 
tnat  data  tase  witr.  relations  define!  so  that  all  non-Kev  fields 
of  any  relatlpn^l  tuple  are  functionally  dependent  on  eacn  of  ttie 
Key  Jlelos  of  tnat  tuple;  tMs  is  Kno<in  as  "tnlro-normal  form" 
ano  can  a]vavs  ne  ieriveg  for  a  data  oase.  Having  a  relational 
model,  *e  car  next  oerive  a  relational  hierarcny  from  the 
reiatior  nares  as  aoove,  sucstltutinu  synonyms  where  necessary  to 
allow  as  mucf  merging  as  possiole  of  downward  paths  in  tne 
Merarcty.  In  this  way,  *e  get  In  effect  a  maximally  factored 
tMrd-normal  for"  relational  model.  f 

^5  a  xirc  of  lojlcal  data  base  •'rgdel,  a  relational  hierarchy 
nas  tre  acvartage  of  oelng  oractically  Invisible  to  a  user.  Its 
structure  Is  simply  an  analoo  of  natural  language  word 
modi f Icat 1  on  and  should  not  nave  to  ne  soelled  out  tor  a  user  who 
Knows  fnalish  aii.i  who  is  a  little  familiar  with  the  contents  of  a 
olven  dots  rase.  mat  «e  nave  done  here  is  to  eliminate  some  of 
the  oeorees  of  freedom  tn  a  relational  approach  so  as  to  maKe  it 
more  compatlole  »ltn  tne  way  tnat  non-expert  data  base  users 
might  intuitlvelv  perceive  information.  The  scheme  is  extremely 
simple,  rut  In  practice,  it  seems  to  worK  out  tairly  well  as  a 
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r;-islb  tf'r  roi'i  icpr  proir-i’s  t*'  sense  of  bmiisn  'queries 

jirecte'’  AnojOb'  ^  fr,r  :'-»tien  ':-it  t  r.rjse. 

.'ive''  r^litloi'il  rilerTrcTies  means  of  query 

interpret  for ,  »  naturai  ioni..iiaqe  querv  facility  falls  neatly 

ino  t'*c  olslinct  n-irts:  a  ianiuaie  analysis  co.noonent  tnat 
PriPses  Irro'^jp)  lerif-s  an  j  -ars  tnem  into  nata  references 
relccive  tp  a  r  e  1 ->t  i  ona  i  ■.  ierarcfiv  oata  (O'iel;  ann  a  tarqet 
translatrr  c n  .nnne  -.t  fnt  .’la-s  raferences  to  a  iooicai  aata  base 
ii'Onel  irto  r*-terercas  to  an  uiti'^ate  target  aata  oase,  Havina  a 
relotlorai  '.ler-ircny  as  an  inter  ■■eoiate  sten  oer  nits  lanquaqe 
analysis  to  ;e  levelooeo  an  ter er-oent  of  Cbe  tarqet  translator, 
ann  f.us  imeren  lent  of  tne  tar  >et  bata  oase  itself.  This 
ureatly  eniances  oortaoility  ot  tne  uuery  facility  at  the  front 
er.a. 


/,  /  ftn  ii  t  ert  e  iiaL»  .;uery  Ian  uaoe 

I  r  ar  s lat  ill -j  an  inout  query  mto  an  interr.'eqiate  lanqua  ie  is 
a'ivant6c»oi.s  In  several  *ays.  Ttie  'inst  important  consideration 
is  odr,]  ar  it  v:  it  breaks  uo  trie  query  orocessim  problem  into 
t*o  -rore  men  jeacle  t'ieces  fro.i.  tne  standpoint  of  established 
corfH'tai  loral  rectinloues  for  romriitrio  and  translatlnq  ianquanes 


er'd  for  retrievirn  irtta  tnrouon  tornal  queries.  This  sort  of 
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I’onuldrltv  rtiso  enhances  t^e  'utin-ot^*  nortaniiicv  of  a  natjral 
lan'3iiatic  cuerv  farilitv  in  tf.at  tne  moat  ouery  processor  can  oe 
oeslonec  wltt^  a  "  of  ass'i 'r  t  lors  anout  an  actual  tanet 

data  ties*. 


f  roii  r^'e  pe'-serjct  J  ve  of  tne  user,  tna  oisolay  of  an 
Int  ern.eoiat  e  translation  is  nelnfu)  for  verifvini  tnat  ouerv 
processlno  is  lu  f -iCt  nrocee<-ir.  i  correctly.  Tne  oerivation  of 
relational  r.ierarcnies  on  tue  tasis  of  lir.ouistlc  "'looi  f  icat  Ion 
raises  it  fairlv  easv  for  a  user  to  unoerstano  an  Interii'ediatc 
ouery  vittouf  really  navini  to  i^no*  all  tne  tnlnJS  necessary  in 
order  to  construct  one  correctlv.  mere  is  of  course  a  Hazard  in 

ext'oslnu  a  user  to  so^-.p  ot  t;ie  tecnnlcal  details  of  query 

\ 

rrocessin<i,  rut  or  tne  Atole,  it  s^ets  "^ore  nalanced  off  tv 
nae.lno  suerv  orocessim  less  Tysterious  to  trie  user  and  qivinj 
tne  user  sore  control  over  it. 


An  altouetner  oifferent  "otivatlon  tor  iriter’reoiate 
translatior  arises  oecause  of  tne  need  to  oeal  vltn  tne  nronlem 
of  fironouns  arn  otner  noT.inai  expressions  tnat  riave  to  oe 
unoerstoof’  Iri  context.  in  o“neral,  this  reou ires  that  an  access 
facility  le  arle  to  save  previous  oueries  in  a  xay  tnat  allows 
Irfornatior  to  ne  “xtracte-i  frnn-  tfie-n  *nen  nee-ied  to  interpret 
references  ot  a  current  ouerv.  me  InterT.ediate  lanouaqe  forti  ot 


queries  turris  out  to  ne  convenient  tor  tnis  ouroose  [see  Section 
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4.1  tor  detai  ls  I . 

We  miatit  draw  an  analO''jy  oitn  tne  si.nilar  tecnnlTue  of 
Savina  ar  Inter^nedlate  lanuuaae  onase  in  a  con, oiler  for  a 

proqraii.mino  lamuaoe.  It  Is  a  stanoaro  aonroac.^  for  maKinq  coae 
optimization  easier  to  oo  ano  for  Oesloning  coTipilers  to  oe 
portable;  and  ir  can  be  effective  as  *eli  In  otner  language 

apolicatiors.  hv  oeim  careful  in  tne  cnoice  of  an  intermediate 

lanquace,  we  can  greatly  simnllfy  the  orooleT.  of  processina  any 
lanquaoe,  sonetnlna  especially  ii'.oortant  wnen  dealing  with 
linguistic  complications  on  tne  order  of  those  arising  in 

finollsh . 

The  Irter'tiedlate  duerv  language  assumes  tnat  all  data  of 
Interest  can  ne  organized  into  a  logical  hierarchy  or  relations, 
where  a  relation  could  oe  thought  of  as  an  aostract  record  type 
with  certain  oefinen  fields  tor  noUlm  specific  Kinds  of  data. 
For  example, 

A1PCI<AFT  (country,  designation] 

!  .  .KlijELiAuK 

•  « 

•  • 

:  :  .  .Dl’^FuSlU'j  (lencitn,  width] 

:  .  .  f-yCI  Jt  l»,  manufacturer,  thrust] 
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Tne  locic>il  nier'trcny  ot  dn  Aircraft  data  case  with  4 
relations  am  /  fields  detlrieo. 

An  interr’eilat.a  auerv  is  a  series  of  "clauses"  reterrlna  to 
such  a  rlnrarcny.  it  is  expressed  as  a  list  ot  the  clauses 
terfflnafeo  tv  tne  syrnooi  (,) 

ri.M'5K  -  1 

.  CIAt'.Sl  -  2 


.  rt-AI'f-*'  -  n 


( .  ) 

A  ireceoim  a  clause  indicates  dependence  on  a  previous 
clause;  it  is  a  <ino  of  continuation  TiarKer.  The  first  clause 
In  an  InterTiediate  nuerv  ir.av  or  may  not  he  dependent;  all 


suhseouent  clauses  in  tne  ouery  oust  oe 
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Kach  clause  traces  a  oatn  tnrouir,  tne  relational  nierarcny 
ot  a  oata  case,  startino  froin  tne  too  of  a  nierarcny  for 
IndeperOert  clauses  anci  orancrinq  oft  oreviously  cefineri  patns 
tor  aefender.t  clauses.  nacn  oatn  car,  ne  tlou'int  of  as 
cor responoino  to  a  cnain  ot  relational  instances  (actual  lonical 
data  recoros)  riatcninq  the  conditions  of  a  clause. 

^  clause  is  exoressei  in  tne  oeneral  foriT' 

H  h-7  ...  Rn(dnH  yi,02 . Qk  I 

vihere 

Pi  are  relation  na-nes  In  a  oata  nierarcny 
VI  are  soecial  action  nancers 

t1  are  orenicate  o'  aiifiers  on  relational  fielos 
(enclosed  in  square  oracKets) 

Helatlon  nanes  »111  always  oe  one  vori  loni  to  avoid 
ambiquity  profclens.  rne  sequence  ot  relations  HI  H?  ...  Hn  in  a 
clause  nust  trace  a  continuous  oo«n*ard  cnain  in  a  relationl 
nierarcny,  for  an  Iniepennent  clause,  wi  must  oe  tne  top  ot  tne 
nierarcny.  In  tne  relational  nierarcny  fron  above, 


,  f  I'llMKiviiiMN'' 


"AIKCPAfT  K'iGl  lK" 
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"AIRCPAFT  FtJSl^LAGE  DIMENSION" 

"AIRCRAFT"  are  all  oosslole  legal  sequences. 

A  aualltler  yj  consists  of  a  list  of  field  specifications 
separated  ty  commas,  eacn  specification  is  of  the  form 

Fleldrame  ar Itnmetlc-comparison-operator  value 

There  are  a  number  of  conventions  with  field  names: 
o  a  field  name  in  an  intermediate  Query  may  have  a  function 
name  associated  with  it.  with  the  function  name  enclosed  in 
parentheses.  For  example,  Kmaximum)  length**],  in  this 
case,  the  procedure  is  first  to  looic  for  a  field  name 
"maximum  length";  it  there  is  ho  such  field  in  a  data  base, 
then  the  field  "length"  is  searched  for  in  the  data  base 
mooel  and  if  found,  the  function  "maximum"  is  applied  to  all 
fielas  of  relational  instances  to  yield  a  resultant  value 
for  comparison  or  return. 

o  secondary  Keys  enclosed  in  <<..,>>  may  be  part  of  a  field  name 
in  an  intermediate  query.  These  may  be  in  two  forms, 

<<x=y>>  or  simply  <<x>>.  These  allow  for  the  value  of  a 
field  to  be  actually  an  array.  The  first  form  <<X=Y>> 
selects  a  column  or  row  or  plane  of  an  array  explicitly.  The 
second  form  allows  for  field  names  of  the  form  "X  field  name"; 
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It  no  such  flela  exists,  then  field  Is  assumed  to  be  an  array 
and  X  Is  assumed  to  be  a  parameter  for  selecting  a  value 
associati vely .  It  Is  assumed  that  given  X,  le  can  find  what 

parameter  It  must  specify  by  looxlng  at  tne  array.  In  other 
vioras,  tne  intermediate  query  need  not  say  this  exollcltly. 
o  " » "  Is  a  special  field  name  for  no*'  many  of  an  on ject 

corresponding  to  a  relation  is  associated  with  an  object  of 
the  parent  relation. 

Values  will  have  associated  conventions  also.  It  Is  assumed 
that  default  units  of  measurement  are  associated  with  fields  of  a 
data  base  and  that  tnese  apply  if  omitted  from  a  value 
specification.  If  an  explicit  unit  is  specified,  then  tne 
intermediate  query  language  processor  has  the  responsibility  of 
convertlnq  units  in  maxing  comparisons.  Exact  matches  of 
numerical  values  are  not  mandatory;  the  data  base  oescriotlon 
should  specify  what  tne  ranoe  of  exactness  should  be  for  various 
fields.  (This  is  not  the  same  as  a  measurement  error.) 

For  example, 

deslqn0tion='''XG-25 ,  count rysUP 


lehqth>100  feet 
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A  value  may  be  the  symbol  which  Is  the  wildcar'l.  This  will 
match  any  value  of  a  field  provided  that  the  field  is  actually 
defined  for  a  olven  relation  instance.  A 
marKer  Ml  can  be  a  uniqueness  indicator  (S)  or  a  question 
indicator  (?),  («?),  (Y/n?)  or  both.  Question  indicators, 
however,  are  rrutually  exclusive.  Eor  example. 


(  ?  )  c !  ) 


(»?) 

Markers  Ml  and  qualifiers  Q1  are  optional  in  a  clause.  If  a 
qualifier  Is  null,  then  it  matches  anything  providing  that  the 
corresponding  relational  instance  is  actually  defined. 

For  an  Independent  clause,  the  procedure  for  interpretation 
is  as  follows  for  qualification: 

0  start  at  the  top  of  tne  hierarchy. 

o  retrieve  all  relational  instances  compatible  with  qualifiers, 
o  if  a  lower  level  of  relations  is  specified,  retrieve  all  lower 
relational  Instances  chained  to  those  already  retrieved  and 
having  compatibility  with  qualifiers  at  the  lower  level, 
o  continue  this  until  either  the  end  of  the  clause  is  reached 


or  no  relational  instances  satisfy  a  qualifier 
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For  dependent  clauses,  the  proceaure  is  similar: 

o  start  at  the  current  place  In  the  relational  nierarchy,  i.e. 
t>here  the  precedina  clause  stooped. 

o  try  to  Interpret  tne  clause  as  apolyina  to  the  subhierarchy 
of  relations  at  the  current  Place  and  referrim  only  to 
relational  Instances  satisfying  the  preceding  clause. 

o  if  the  first  relation  of  the  nependent  clause  does  not  txlst 
Immediately  below  the  current  relation,  bacic  up  one  level  in 
the  relational  hierarchy  ana  try  again. 

0  in  fcac<ing  up,  retain  only  those  higher-level  relational 

Instances  chaining  with  a  matched  relational  instance  at  the 
lower  level. 

The  procedure  tor  qualification  selects  certain  subsets  of 
relational  instances  for  each  of  the  relational  types  soeclfied 
in  a  query.  The  mar<ers  of  an  intermediate  query  Identify  what 
subsets  are  of  interest,  as  well  as  tne  type  of  action  to  taice 
with  them  in  response  to  the  query. 

0  (nl)  This  specifies  that  only  n  relational  Instances  should 
match.  If  n  is  preceded  by  the  operator  *>'  or  *<', 
tnen  it  specifies  that  more  than  n  or  less  tnan  .n  should 
match.  If  n  is  omitted  entirely,  the  maricer  Is  for 
definitions  with  a  specific  number. 
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o  (?)  mis  specifies  that  all  Key  fields  and  all  ♦  fields  of 
tPe  h.arked  relation  are  to  oe  presented  to  the  user  for 
the  iratched  relational  Instances, 
o  (»f)  This  asKS  only  for  a  count  of  relational  Instances 
matched. 

p  (y/n?)  mis  asks  for  a  yes  or  no  answer,  depending 
on  whether  any  relation  Instances  match 
tne  conoitlons  of  a  query. 


Kor  the  most  part,  the  conventions  here  should  be  adequate 
as  a  basis  for  question-answer ing  applications.  The  only  further 
detail  that  needs  elaboration  is  the  problem  of  reference  across 
queries,  where  the  first  clause  of  a  query  is  dependent.  This  * 
would  work  In  much  the  same  way  as  reference  within  a  query,  but 
with  a  complication. 

The  problem  with  cross-query  reference  is  that  this  does  not 
always  refer  to  relational  instances  identified  in  a  previous 
query.  Often  the  Intent  is  that  the  current  query  incorporate 
entire  clauses  from  a  previous  auery  so  as  to  identify  completely 
different  reiatlonal  instances  (i.e.  anaphoric  reference),  Tne 
procedure  for  dealing  with  this  will  be  as  follows; 


1 

1 

I 


I 


0  Assume  t^e  preceding  intermediate  query  is  available; 
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n.etae  the  current  one  into  it,  with  the  current  one 
surerseoim  if  there  are  conflicting  differences. 

0  If  the  result  is  the  same  as  the  preceding  intermediate 
nuery  exceot  for  additional  field  specifications,  then 
interpretation  of  current  otuery  can  proceed  by  applying 
tr.cse  specifications  to  the  relational  instances 
matched  bv  the  precedino  ouery. 
o  If  a  field  specif icatlon  Is  changed  without  any  changes 
in  question  indicators  or  odaltion  of  clauses,  then 
Interoretation  must  start  over  from  tne  beginning  with 
the  irerged  guery.  (This  situation  is  anapnorlc), 
o  It  a  Tiestlon  indicator  is  changed  without  the 

introduction  of  any  new  indicators,  tnen  the  interpretation 
will  proceed  on  the  oasis  of  other  changes  in  the  merged 
duerv,  if  any. 

0  If  a  new  clause  with  a  question  indicator  Is  Introduced  by 
the  current  duerv,  then  ail  unrepeated  clauses  from  the 
preceding  query  having  a  question  indicator  and  tracing  a 
divergent  path  in  the  nlerarcnlcai  relational  hierarchy 
must  oe  deleted,  ana  query  Interpretation  must  start  over 
again.  All  otner  orevious  question  indicators  wiil  be 
drooped  in  any  event. 

0  If  no  new  clause  contains’  a  question  indicator  and  there 


is  no  orevious  question  indicator  at  a  nierarchical  level 
above  a  new  clause,  then  interpretation  can  proceed 
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directlv  from  the  results  ot  the  precedino  Intermediate 
ouery. 

0  If  there  is  a  new  clause  without  a  question  indicator 
below  a  previous  question  Inoicator  combined  with  a 
definiteness  indicator,  then  Interpretation  will  proceed 
as  above  as  If  there  were  no  new  clause.  If  the  definite¬ 
ness  indicator  is  absent,  however,  then  this  is  deemed 
anblouous.  The  requester  is  notified  of  this,  and  it  is 
assume  1  that  Interoretat ion  snould  start  over  from  the 
becirnlnq  with  the  full  merged  ouery. 
o  The  default  for  interpretation  with  reference  is  always 
to  proceeo  from  the  results  of  the  previous  query. 

Examples : 

A  seouehce  of  queries  witn  reference 


AIPCKAFTC?) 

"How  many  planes 

.  FNGlNEC»=i] 

nave  4  engines?" 

(.1 

AIPCPAFTC ?HcouhtrY=ur J  "how  many  Russian 

(.)  ones?" 

Here  we  reinterpret  from  "aihcrakt"  level  with  the  relation 


instances  matched  there 
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.  AIKCI'AFf  KijsKHO:  i,ii)f»(?){lenqth  =  30]  "Ho*  many 

(.)  nave  lenoth 

30?" 

Afplauity  =  lemtn  ot  Wenolre  planes  or  length  of  4-enqine 
Fussier  o lanes? 

Here  *e  vouJo  assume  toe  latter  and  woul-l  Inform  tne  user  of  that 
fact.  I 

2,3  TaMe-criven  translation 

necause  tne  aH  project  was  directed  toward  tne  development 
of  genera]  nata  nase  access  technigues,  *e  had  to  avoid  any 
apprcacr  tnat  denenden  on  any  particular  <ind  of  target  data 
str'icture.  Inis  necame  esoecially  important  in  implementing  a 
oeiT.onsi  rat  j or.  system  for  AOT,  tor  it  had  to  be  clear  that  its 
capaoiiltlrs  *guld  apply  to  large,  complex  oata  oases  from  the 
real  world  as  well  as  to  a  snail,  contrived  demonstration  data 
base.  *e  therefore  adopted  a  taole-drlven  processing  strategy 
tor  AOl ,  where  data  base  denenoent  details  of  access  would  oe 
Kept  serarate  from  tne  operation  ot  a  system  in  external  tables. 

Thf  syrtactic  analysis  ann  rewriting  ot  incut  queries  were 
easy  to  nar.dle  in  tnls  manner  oecause  they  Involved  the  Kinds  of 
lecr.nlnues  already  evolved  tor  syntax-directed  translation  of 
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progr  imirlr.g  languages  [11  ana  t^e  construction  ot 

compiler-conpilers.  In  tne  AOT  aDoroacn,  an  Inout  query  language 
Is  defined  oy  a  table  ot  rules  of  grarrimar  and  a  dictionary  taole 
of  vocabulary  for  a  particular  target  data  base.  The  semantics 
of  a  query  lamuage  is  defined  oy  procedures  associated  with  each 
rule  of  granmar  and  each  aictlonary  entry;  these  procedures, 
encoded  as  strims  to  be  read  ny  special  interpreter,  are  also 
Kept  eytcrnal  to  a  system.  ' 

For  the  translation  of  natural  language  queries  into 
intermediate  queries,  tne  oroolem  of  aot  was  to  provide 
convenient  but  yet  powerful  enough  facilities  to  getine  the  Kinds 
of  grammars  and  dictionaries  reouired  for  natural  language  and 
also  to  provide  a  flexible  parser  tnat  could  be  driven  by  these 
grammars  and  dictionaries,  nnr  solution  to  grammars  vat  to 
express  them  using  context  free  rules  with  extensions  in  the 
direction  of  van  iviqngaarden  grammars  [131  for  additional 
descriptive  powers;  these  extensions  were  constrained  so  that  we 
could  still  basically  employ  familiar  techniques  for  parsing 
context-free  languages,  uictlonaries  posed  no  major  difficulty 
•with  a  semantic  scheme  of  strinq  manipulation  through  text 
editing  primitives;  words  could  oe  oeflned  simply  as  sets  of 
ASCII  character  strings  oassed  as  arguments  to  semantic 
procedures.  Section  3  will  describe  this  is  more  detail  and  will 
go  Intd  an  approach  to  a  casic  grammar  tor  natural  language 
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f^ueries. 

I 

The  AvT  parser  pIjs  -in  interpreter  for  semantic  procedures 
constitutes  ».nat  we  call  the  "AWT  Interme-iiate  translator", 
produclnu  tornai  inter neniate  -juery  strings  from  natural  language 
ouerles.  To  cofu-lete  a  guerv  facility,  we  need  a  way  of  mapping 
an  interreoiate  guerv  into  actual  references  to  a  target  data 
base.  nne  rossibUitv  is  to  translate  it  into  a  data  access 
language  alreaiy  netineo  tor  tne  target  nase,  but  this  is  not 
always  feasirie;  a  data  access  language  may  not  always  exist  or 
it  may  rot  be  anle  to  suocort  tne  capaoillties  that  we  would  want 
for  natural  ian-juage  access,  or  it  may  oe  too  bard  to  map  Into, 
requiring  the  equivalent  of  neing  able  to  generate  programs 
automat  leal ) v. 

The  approach  currently  taxen  oy  aqt  is  to  access  a  target 
data  base  olrectly,  assuming  that  it  is  organized  into  records  or 
some  similar  data  construct  and  that  there  exists  a  procedure  for 
getting  these  records  from  tne  oata  base.  The  AQT  target  data 
base  translator  maos  an  intermediate  auerv  into  a  data  access 
sequence  of  references  to  particular  fields  In  particular 
records.  If-e  oata  access  sequence  is  aoolled  in  searching  a 
target  oata  base  to  retrieve  recoras  matching  specified 
conditions,  am  then  selected  fields  of  these  records  are  printed 
in  response  to  tne  original  query. 
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LlKe  tte  Interneoiate  translator,  tne  target  data  nase 
translator  can  ne  oraantzea  as  a  tanie-driven  scneme.  It  is  a 
some*nat  ncre  diftlcult  oroblea  in  that  tnere  are  fewer 
estahllsheo  tecnhnionjes  to  draw  uoon,  bnt  from  any  oractical 
standpoint,  it  is  unavoidanle.  Tne  issue  here  is  not  only  that 
of  maKinq  it  easier  to  orino  ip  a  query  facility  on  different 
tarqet  data  oases,  out  also  that  of  accomtr.oaat  1  no  tne  almost 
inevitable  arowth  of  a  tarnet  data  nase  when  it  is  discovered  to 
contain  useful  information  accessible  In  a  convenient  way. 

The  oasic  ca.oles  involved  ir  taraet  data  case  translation 
define  a  cor responaence  between  fields  wltnln  a  relational 
nlerarcry  ano  fields  of  taroet  data  case  records  ano  between 
functional  deoenoence  of  fields  In  the  hierarchy  and  data 
linifages  iTplemented  in  tne  tar  jet  data  oase.  we  cannot  actually 
descrlne  all  possible  cor responoences  of  tnls  sort  because  tne 
ways  of  oroanizinq  a  target  data  base  are  infinite:  out  we  can 
accommodate  tne  most  c'ommon  Kinds  of  target  data  fields  ano 
linkages  wf lie  allowino  for  the  inclusion  in  a  system  of  special 
procedures  to  nandle  tne  exotic  cases.  Section  4  and  5  go  Into 
this  in  more  detail. 
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i.l  tletrerts  ot  a  cuerv  icinqu-^-ie 

Aie  nave  to  ne  ^ore  soeclflc  nere  aoout  wtiat  we  'nean  by  a 
natural  iarun-rie,  for  tne  *ord  "natural"  in  tne  past  has  been 
applies  1(1  £  tewiiierinj  variety  ot  senses.  For  exa^nple,  COBOL 
is  sonetlfres  caUeo  natural  because  it  en.ploys  Enuiish  words 
extensively.  Fr-l,  [inj  because  it  allows  users  to  extend  a 
languaoe,  shwcli  C14J  because  it  can  maxe  intellloent  inferences, 
and  most  systems  tynicallv  oecause  tney  accept  input  with  a 
syntax  rased  on  tne  structure  of  sentences  in  a  language  ll<e 
Fnqllsh.  Ir  tne  extreme  case,  naturalness  could  conceivably  be 
stretcher)  to  enco.r.pass  anything  not  artificial,  not  associated 
witn  nactilres. 

Ir  /lyT,  naturalness  has  a  restricted  sense,  largely  because 
we  are  srecifically  addressing  tne  problem  of  data  base  access. 


with  any  ojven  data  nase,  tne  winds  of  responses  that  can  be  made 
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to  a  query  are  actually  quite  limited;  answering  yes  or  no  to 
the  existence  of  data  Items,  giving  counts  of  items,  printing  out 
some  combination  of  fields  from  selected  target  data  base 
records,  printing  out  documentation  aoout  the  oata  base  Itself, 
prompting  the  user  where  a  decision  cannot  be  maoe  automatically, 
and  displaying  diagnostic  information  about  the  course  of 
processing  a  query.  The  problem  of  natural  language  here 
therefore  reduces  to  the  question  of  now  to  let  a  person  elicit 
such  responses  in  a  natural  way. 

From  a  practical  standpoint,  we  can  assume  that  a  user  of  a 
query  facility  will  generally  want  responses  that  yield 
Information  from  a  data  base.  This  means  that  queries  can  be 
expected  to  refer  to  the  structure  and  content  of  a  data  base  as 
perceived  by  tne  user.  Relational  nlerarchies  are  introduced 
here  In  an  attempt  to  model  a  typical  user's  perception  of  data 
bases  and  therefore  provide  a  way  of  classifying  the  possible 
referential  constituents  of  queries,  which  in  our  case  would 
Include  relations,  field  names,  and  literal  values. 

To  make  tne  scheme  here  as  transparent  as  posslnle  to  the 
user,  we  do  not  require  the  user  to  oe  aware  of  referring  to  a 
relational  hierarchy,  and  we  do  not  of  course  out  any  restriction 
on  how  such  (implicit)  references  to  a  hierarchy  are  combined  In 
a  query,  we  will  assume  only  that  queries  will  oe  such  that  they 
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are  Intelllainie  at  least  to  tne  user  entering  them  and  that,  In 
the  absence  of  any  other  conventions  for  communication,  the  user 
will  use  something  resembling  English  syntax. 

Our  approach  to  the  analysis  of  queries  will  first  be  to 
Identify  individual  words  in  a  query  In  terms  of  semantic 
significance  In  a  relational  hierarchy:  relation,  field  name, 
literal  value,  and  so  forth;  this  will  be  done  through  a 
dictionary  of  query  language  vocabulary.  Then  we  will  attempt  to 
associate  literal  values  wltn  appropriate  field  names,  field 
names  with  relations,  and  relations  with  other  relations 
according  to  their  nlerarchical  ordering;  this  will  be  done 
through  a  grammar  of  expected  patterns  of  words  with  various 
iclnds  of  semantic  significance.  The  result  of  all  this  will  be 
an  Intermediate  guery  to  be  passed  on  for  further  processing. 


3.1.1 


To  define  a  guery  language,  we  first  of  all  need  a  grammar 
to  specify  the  various  basic  constituents  of  the  language  and  how 
these  combine  to  form  larger  constituents  up  to  the  level  of 
sentences.  In  AOT,  a  grammar  -consists  of  context-free  rules  (see 
[1])  of  the  form  x->Y  Z,  stating  that  adjacent  vr-  and 
Z-constltuents  together  can  become  an  x-eonstltuent  regardless  of 


i 
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context,  ana  X->Z,  stating  tnat  a  z-constituent  Is  also  an 
X-constltuent  regaraless  ot  context.  More  complex  rules  of 
grammar  than  this  are  usuallv  employed  In  natural  language 
applications  since  context-free  rules  cannot  fully  oescrlbe  tne 
syntax  ot  these  languages,  out  for  AQT,  such  rules  simplify 
greatly  the  problem  of  parsing  queries  and  »ith  a  few  simple 
extensions  can  oe  quite  adequate  for  query  language  description. 

A  serious  descriptive  shortcoming  of  context-free  grammars 
is  in  the  number  of  rules  needed  to  deal  witn  any  nontrivial 
aspect  of  natural  language.  A  simple  example  nere  is  tne  case  of 
noun  phrases  and  determiners  liice  "a"  and  "the."  wnen  a  noun 
phrase  already  starts  witn  a  aeterminer,  there  are  syntactic 
conseguences  H<e  rulina  out  anotner  determiner  in  front  and  so 
the  noun  phrase  ought  to  oe  marxed.  This  can  be  done  by  having  a 
new  constituent  type  n^P  for  determined  noun  pnrases  as  opposed 
to  just  NP;  but  tnis  al-so  leads  to  a  proolem  because  dnp  in  many 
situations  is  still  equivalent  to  np,  forcing  us  to  duplicate 
many  rules  ot  grammar  that  replace  “iP  witn  Dmp.  The  problem 
worsens  with  more  dimensions  for  mar>cing  a  constituent  type, 
because  the  numoer  of  extra  rules  needed  grows  exponentially. 

Fortunately,  there  are  ways  around  the  difficulty  nere,  and 
in  fact  grammars  in  AQF  employ  several  of  them  to  orovlde  as  mucn 
flexibility  as  possible  In  language  Sbecitication.  A  simple,  out 
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powerful  enlianceTient  to  context-free  rules  Is  to  allow  syntactic 
features  to  be  attacned  to  a  constituent  type  X  as  a  qualifier, 
written  as  X Cf.G, . . . ,k1  wnere  F,G,...K  are  features.  On  the 
riont  side  of  a  rule  of  qrammar,  features  specify  conditions  on 
subconstltuer.ts  that  must  hold  tor  the  rule  to  be  applicable;  on 
the  left,  the  features  are  those  tnat  are  to  be  turned  on  upon 
qettino  a  new  constituent  tnrouqn  a  rule.  The  attachment  of 
features  to  syntactic  categories  allows  a  single  rule  of  grammar 
to  stand  for  an  entire  family  of  ordinary  context-free  rules; 
this  xind  of  extension  turns  out  to  be  along  the  lines  of  van 
wijnqaarden  qratnmars,  which  have  oeen  shown  to  oe  adequate  for 
descrlMno  any  language  recognizable  by  an  automaton  tl31. 

Another  enhancement.  In  sense  even  more  powerful,  is 
incorporated  in  tne  semantics  for  a  grammar.  In  AQT,  the 
semantics  of  a  rule  of  grammar  is  defined  by  a  procedure  attached 
to  the  rule,  as  done  In  tne  syntax-driven  translation  of  computer 
programming  languages  til.  The  particular  scheme  in  AQT,  derived 
from  the  liNGOL  system  [9j ,  allows  semantic  procedures  to 
communicate  through  snared  variaoles.  The  effect  of  this  is 
about  the  same  as  for  syntactic  features  In  that  a  procedure  for 
a  rule  can  execute  code  conditionally  on  these  variables  and 
therefore  naXe  tne  rule  equivalent  to  a  family  of  rules  with 
different  s-eirantlcs,  A  broader  discussion  of  semantic  procedures 
for  rules  of  grammar  cones  in  Section  3.2. 
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3.1.2 


The  AvT  approach  is  flexible  enoiiqtj  to  let  users  define 
their  own  auery  languages  froi'  scratch  by  supolyinq  grammars  and 
dictionaries.  In  practice,  noAever,  this  Involves  a  great  deal 
of  worlf,  much  of  it  duolicated  in  oitferent  language  since  in  AOT 


they  all 

will  first 

be  translated 

into 

A 

fixed 

intermediate 

language. 

It  is 

therefore  reasonanle 

and 

nelpf ul 

for  a  query 

facility 

to  include 

a  nasic  query 

languaoe 

grammar 

at  least, 

somethlna  that  could  be  elaborated  on  if  necessary. 

The  basic  A<3T  query  language  is  a  suoset  of  English 
revolving  ralnly  around  nouns  ano  noun  ■nodifiers,  given  our  focus 
on  data  bases  about  things  rather  than  events  or  processes. 
Verbs  occur  in  the  language,  out  olay  a  fairly  minor  role  since 
they  seldom  will  map  into  anything  soecific  in  a  relational 
hierarchy.  Omission  of  verbs  in  a  uuerv  is  in  tact  allowed  ov 
AQT  so  as  to  reduce  tne  work  necessary  In  entering  a  query. 

The  basic  AOT  query  language  grammar  mostly  deals  with  words 
denoting  relations,  fields,  and  literal  values  in  a  relational 
hierarchy  and  now  they  combine  within  noun  phrases.  Tne  purpose 
of  the  granmar  was  ngt  to  be  exhaustive,  out  rather  to  orovioe  a 
simple,  practical  scheme  adequate  for  wnat  miant  reasonably  be 
expected  in  the  actual  querying  of  data  bases.  Tne  scheme 


-if 
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essentially  notes  that,  in  a  noun  ohrase,  value  references 
associate  fcith  field  soecif Ications  and  field  specifications  with 
relations,  eventually  annunting  to  a  clause  in  an  intermediate 
duery.  The  systax  for  this  kind  of  association  in  English  is 
quite  varleo. 


relation 

field 

value 


relation 
"aircraft  vjlnn" 
"l-nuth  dimension" 
"fighter  aircraft" 


field 

"aircraft  name" 


"124  feet  long" 


value 

"wing  swept" 
"type  X" 


Tnls  suggests  that  a  Basic  query  language  grammar  should  be 
something  simple  like  this; 

SF  ECIKICAri.lN->VAH.lE 
5PKCIKICAT10N->F1KLD 
SFfCIFICATlON->KTEbO  VAIA'E 
SPFClF[CATrON->VALl/E  Kifc;LD 

AFbATKl  »-PATM->SPECIF1CAT10n  KELATION-PAIH 
Pf;bATl'J''i-PArd->RetiAT ION-PATH  SPECIFICATION 


KFLATIihl-PA  l'ii->PEL AT  10  < 
P>LATi:)N-PArH->KELATION  REbATI ON-PATH 
C'UKHY->KKL,ATlt)N-PArH 
OllEI<y->HFbAriON-PATH  C'UKHY 


This,  of  course  wovild  have  to  be  filled  out  in  considerably 
more  detail.  The  grammar  still  needs  to  deal  with  such  problems 
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as  determiners,  quantltlers,  question  word  li)<e  "what," 
negatives,  vero  ofirases,  prepositional  onrases,  and  so  torth,  as 
well  as  clarifylno  the  semantic  criteria  for  tne  appllcaoilitv  of 
the  aoove  rules.  r.ne  basic  scneme,  nowever,  will  remain  tne  same 
because  of  the  fact  that  we  win  always  oe  irapolna  queries  into  a 
relatiorial  hierarchy. 


3.1.3 


In  Ai'l,  a  word  is  put  into  a  query  language  vocabulary  oy 
assigning  a  syntactic  category  and  a  semantic  procedure.  Haslc 
syntax  words  lltce  "the"  will  oe  oefined  within  tne  basic 

grammar,  but  vocaoulary  specific  to  a  target  data  oase  will  have 
to  be  defineo  separately.  The  syntactic  categories  tor  this  are 
as  follows: 

Pfc'.LN  A  noun  identitylno  a  relation,  e.g., 

"aircraft."  This  has  syntactic  fea¬ 
ture  iwoPii  mariclnq  oossible  use  as 
post  modifier  of  a  field  expression. 

VKPBtRELa]  A  relation  expressed  as  a  vero,  with 
mandatory  syntactic  features,  e.g., 

"f ly." 

ADJ  A  relation  expressed  as  an  adleccive, 

e.g.,  " p 1 q . " 

FLDN  A  noun  consltuent  of  a  field  name, 

which  may  include  more  than  one  word, 
e.g,,  "name."  This  has  three  oossible 
syntactic  features: 

HtAn  s  can  ne  head  word  of  noun 
phrase. 

«unF  *  usually  used  as  a  moditier 
of  head  words. 

=  usually  requires  a  modi¬ 
fier,  implies  MEAh. 


•’*ir 
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FI,  IV 
FLFA 
1  VFk 


riHk  [G^;  iP) 


FKt  Y 


LSI 


A  ti«id  name  expressed  as  a  verb,  e.q., 
"welgr'.." 

A  field  na^ne  expressed  as  an  adjective, 
e.i.,  "«iide." 

A  general  classifier  in  a  field  name 
that  goes  not  help  to  identify  any  re¬ 
lation,  e.g.,  "distance." 

A  general  classifier  in  a  field  name 
contrloatina  no  information  at  all  by 
itself,  e.q.,  "system."  The  syntactic 
flag  is  mandatory. 

A  word  used  in  many  different  contexts 
to  distinguish  different  field  names, 
e.o.,  "service."  The  syntactic  fea¬ 
ture  aEAn  marKs  possible  occurrence  as 
head  word  of  noun  pnrase. 

A  literal  denotlnu  a  value  tor  a  field, 
e.o.,  "mig-25."  rnis  has  two  possible 
syntactic  features; 

‘itAD  =  can  be  head  word  of  noun 
phrase, 

-tOOF  =  usually  used  as  a  modifier 
of  head  words. 

•iunoers  need  not  be  defined  as  literals; 
they  are  automatically  recognized  as 
category  ■'•m. 


A  user  'ill  not  have  to  be  aware  of  tne  syntactic  category  of  any 
^ord  in  a  query.  Defining  words  oy  syntactic  category  will  oe 
the  job  of  the  oerson  who  sets  up  a  relational  hierarchy  and  the 
translation  taoles  associated  with  it.  This  person  in  turn, 
however,  needs  to  Know  only  the  categories  listed  here,  not  all 
the  various  categories  required  for  a  query  language  grammar. 


3.2  A  rarsino  scheme 


alt  input  query  processing  is  organized  around  a  general 
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syntax-driven  oarsing  alaoritnm  for  context-free  languages  141, 
further  augmented  to  accept  syntactic  and  semantic  restrictions 
on  tne  applicability  of  rules  of  grammar  in  a  given  situation. 
This  approach  iceeos  tb«*  relative  simplicity  of  a  context-free 
scheme  without  being  forced  to  recogonize  only  context-free 
languages.  In  fact,  the  possiole  restrictions  on  rules  approach 
In  oower  that  of  van  wijnaaaroen  grammars. 

The  context-free  part  of  tne  AQT  parser  Is  ta<en  directly 
from  the  I.Ingcil  system  of  Vaugnan  Pratt  191.  It  is  essentially  a 
bottom-up  (Coctce-Kasaml-Younger )  algorithm  combined  *itn  a 
simulation  of  a  topdown  (Karley)  algorithm  to  get  tne  best 
features  of  both,  it  is  driven  by  a  grammar  wltn  syntax  rules  of 
the  form  X->Z  or  X->Y  Z;  the  procedure  is  as  follows; 

Assume  a  sentence  consisting  of  morohemes  at  positions 
0  through  L,  Let  [X,i,1J  denote  a  onrase  of  type  X 
comprising  moroheirres  at  positions  i  through  j. 

Begin  at  position  0  with  the  goal  of  S,  the  sentence 
start  symool  for  a  grammar. 

Let  n  oe  the  current  oositlon.  Generate  onrases  [Z,n,n] 
such  that  Z  Is  a  possible  part  Pt  speecn  for  the 
morpheme  at  position  n  and  sucn  that  a  onrase  of  type 
Z  is  compatible  wltn  a  goal  at  position  n. 

Now  get  consequences  of  all  newly  generated  phrases 
[Z,x,n]  for  current  positionn  n  as  follows: 
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o  For  each  rule  X->Y  Z 

If  a  onrase  has  already  been  generated 

and  X  Is  consistent  with  a  goal  at  Dositlon  m, 

Generate  a  ne«  ohrase  (X^Ti.nl 
o  For  eacn  rule  X->Z 

It  X  is  Inconsistent  *itn  a  goal  at  position  )c, 
oenerate  a  ne-v  nnrase  tX,)c,n) 
o  l-or  eacn  rule  X->Z  » 

If  X  is  consistent  witn  a  goal  at  position  K, 
establish  a  as  a  goal  at  position  (nal). 

Continue  tne  above  until  all  newly  generated  phrases  ending 
at  position  h  have  been  processed.  Then  advance  to  position 
(n+n  and  repeat  until  the  end  of  the  sentence. 

The  consistency  checKs  above  are  not  necessary  for 
correctness,  but  improve  efficiency  oy  assuring  that  no  phrase  Is 
oenerated  unless  it  would  have  been  for  a  top-down  as  well  as  a 
bottom-up  algorithm,  A  pnrase  of  type  X  Is  consistent  with  goal 
w  If  an  X-phrase  can  ever  be  a  leftmost  subconstituent  of  a 
w-phrase.  The  consistency  relation  can  be  established  when  a 
grammar  Is  defined  and  stored  as  a  Boolean  matrix. 

The  parsing  scheme  defined  so  tar  is  sufficient  for  any 
context-free  language,  out  tor  natural  language.  It  Is  rather 
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clumsy.  It  Is  inconvenient  for  nanaiino  grammatical  relations 
lllte  agreement  and  tends  to  require  a  proliferation  of  production 
rules  for  descrinlnq  qrammatical  features  in  a  language,  llice 
Knqlisn.  To  maice  tne  scneme  more  workable  for  natural  language, 
three  restrictions  can  be  adoed  to  tne  basic  bottora-up  parsing 
algorithm. 

Syntactic  Features  rnese  nave  already  oeen  described  in 
Section  3.1,1,  we  can  easily  incoroorate  tnem  into  the  AOT 
parsing  alooritnm  by  simply  testing  tor  the  applicability  of  a 
rule  for  given  s ubconstltuents  before  proceeding.  In  a  van 
wljnoaarden  grammar,  syntactic  types  and  syntactic  features  would 
correspond  to  "nroto-notions"  and  rules  of  grammar  to  "nyper 
rules".  In  effect,  a  rule  of  grammar  is  extended  to  become  a 
family  of  related  rules,  allowing  contextual  linguistic 
dependence  to  expressed  compactly. 

Semantic  Features 

Semantic  conditions  for  the  applicability  of  a  rule  of 
grammar  for  natural  language  will  tend  to  be  less  strict  than 
syntactic  conditions.  we  often  want  to  ^grade  the  semantic 
acceptability  of  different  rules  in  a  given  situation  without 
necessarily  having  to  relect  any  of  them  out  of  hand.  To 
accomplish  this,  it  Is  helptui  for  onrases  to  oe  associated  with 
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sets  of  semantic  features#  similar  to  syntactic  features  but 
malntalnea  In  an  altogether  oltferent  uray.  we  will  allow  special 
clauses  to  be  attached  to  a  rule  of  orammar;  eacn  clause  will 
specify  a  conaltlon  on  semantic  features  of  phrases  for  the  right 
side  of  th  the  rule  and,  it  the  condition  holds,  will  also 
specify  sejantic  features  to  be  assigned  to  the  new  phrase 
generated  for  tne  left  of  tne  rule  plus  a  semantic  rating  of  the 
new  phrase.  this  mechanism  is  helpful  In  choosing  between 
alternate  Interpretations  In  cases  of  a  single  rule  of  grammar 
doing  dounle  dutv. 

Exterrallv  Defined  Attributes 

Tne  LINGC’j  system  uses  LISP  local  variables  to  Implement  the 
manipulation  of  attributes  In  KnutTi's  scheme  of  semantics  for 
context-free  languages  CH.  These  local  variables  are  defined  In 
semantic  procedures  associated  *ltn  individual  phrases,  which  are 
executed  at  the  conclusion  of  a  parse  to  verify  tnat  It  also 
semantically  acceptable,  with  local  variables  having  a  scope  of 
definition  over  a  given  ohrase  and  all  of  Its  subconstituents, 
semantic  procedures  can  communicate  with  each  other  regardless  of 
the  syntactic  independence  of  their  respective  phrases.  AQT 
talces  a  parallel  aoproach  with  semantic  procedures  and  local 
variables;  It  allows  for  variables  to  be  declared,  set,  and 
tested  within  procedures  and  for  a  procedure  to  reject  a  parse  If 
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sppciflea  conditions  are  not  met.  I'nls  arranqement  orovides  Ayi 
with  most  ot  its  parslm  power  oeyond  tnat  ot  tne  basic  bottom-uo 
scheme  driven  oy  context-free  qran.'aars. 

All  three  of  these  restriction  .lecnanisms  are  quite  general, 
not  at  all  limited  to  natural  languaoe  aoo I ications .  Our 
particular  Interest  in  natural  lanquaae  suggests  tnat  we  miqnt  go 
even  further  in  tne  development  of  tne  parser.  This  will  make  it 
less  appropriate  for  certain  classes  of  context-free  languages, 
but  will  help  It  to  be  more  efficient  for  languages  like  English, 
a  prime  cons loeration  wnen  working  with  minicomputers. 

Tne  main  ennancement  ot  tne  parser  deals  with 
rlgnt-recurslve  rules  of  aram.mar ,  important  because  natural 
language  (except  for  tne  single  case  of  Japanese)  tavor  right 
recursion.  Tne  oarsing  aluoritnm  as  described  so  far  would 
establish  Identical  nocils  for  each  ot  tne  phrases  ot  identical 
syntactic  type  in  a  right-recursive  nesting,  resulting  in  many 
extra  phrases  being  parsed,  ^e  know,  nowever,  that  only  the 
outermost  phrase  in  a  right  recursive  nesting  need  ne  considered 
in  a  natural  language.  Tne  parser  tnerefore  includes  code  to 
recognize  this  special  case. 

An  enhancement  is  included  also  tor  one  particular  kind  of 
left-recursive  rule  Involving  an  inflectional  suffix.  The 
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ste"'iTier  autoTatlcallv  re:noves  sucn  a  sutflx  as  a  distinct 


morpnen  e 

to 

oe  put 

oacK 

later 

by 

a  left-recursive 

rule 

of 

grammar . 

1  ne 

result 

ot 

this 

with 

a  let t-to-r ight 

parsing 

aluoritnm 

as 

1 A  0  r. 

Is 

tnat  all  tne 

new  Phrases  generated 

as 

conse>}uence  ot  cne  root  of  a  *ord  must  oe  regenerated  for  tne 
qraiT.mat  ical  combination  ot  tne  root  plus  a  suffix.  Tnls  special 
case  Is  easil'/  recocinized,  ana  oy  ludlclous  relahellng  of 
pnrases,  all  regeneration  can  ne  eliminated. 

Tnese  two  special  cases  tor  recursive  rules  ot  grammar  and 
tne  tnree  recnanisiAs  for  restriction  descrioed  above  snow  tne 
main  tnlrcs  to  note  In  order  to  get  a  oroad  idea  of  now  tne  AOT 
parser  worxs. 

3,3  Text  editor  semantics  for  rewriting 

because  tne  parser  In  Ayr  has  to  translate  a  natural 
language  input  guerv  string  into  an  Intermediate  query  string, 
tne  semantic  procedures  for  rules  ot  grammar  In  AOT  need  a 
general  aollity  to  -nanipulate  strings.  As  a  result,  semantic 
procedures  In  AyT  are  defined  in  terms  ot  text  editing  primitives 
along  with  nasic  programming  <;ontroJ  structures.  The  primitives 
refer  to  two  types  of  data  opiects;  puffers  In  wnlcn  strings  are 
operated  upon,  and  varlaoles  storing  a  single  character,  a 
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oolnter  to  a  string  in  a  dictionary/  or  a  oolnter  to  a  list  of 
strina  pointers. 

Fverv  constituent  of  a  guery  as  rjerived  in  narslna  is 
associated  mltti  a  semantic  nroce<lure  through  the  rule  ot  grammar 
descrlnlno  the  constituent.  Kxecutlon  of  procedures  In  toD-doj<n, 
■«ilth  the  procedure  tor  tne  constituent  corresponding  to  an  entire 
query  runnlnq  tirst.  This  oroceoure  *111  In  general  call  the 
procedures  for  Its  iT.mealate  suoconstltuents  and  they  in  turn 
thelrS/  qoino  on  down  to  single  words  with  procedures  that  can 
only  Insert  strings  into  a  nvjtter  or  set  varlaoles. 

Prior  to  any  execution,  tnere  Is  only  a  slnaie  empty  buffer, 
with  no  variables  defined.  A  semantic  Procedure  can  append  to 
the  current  contents  ot  a  nutter  or  snlit  ott  a  new  emoty  nutter 
and  transfer  processing  to  It  tenoorarHv;  along  tne  way, 
variables  can  ne  declared,  set,  ana  tested.  Fransterring 
processing  to  a  new  buffer  'lasKs  all  previous  butters,  and 
declaring  a  varlaole  masKS  Previous  variables  ot  tne  same  name, 
duffers  and  variables  are  accessible  to  all  procedures,  but  must 
be  deallocated  upon  return  trom  the  nrocedure  creating  them, 
restoring  access  to  brevious  nutters  and  variables.  Upon 
conclusion  of  all  execution  of  all  execcitlon,  there  Is  again  a 
single  butter  with  no  variables  defined,  but  the  butter  now  will 


contain  an  output  string 
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Here  is  an  example  of  some  semantic  procedures  in  AQT; 
(lires  preceded  by  are  comments) 

rule  np->!;;lE'^enT  t^P 

;SrAKC  riKw  CLAUSE 
L,I 

;eXfcC'JI>:  (••')«  "ELE'IE'.T” 

LEP'T-PPuCK'DdHE-CALI. 

;EXHCIIfh'  F'W  ""JP" 

UGHT-PHOCtiJUHE-CALL 
PC  r JH  J 


rule  MP->EL.K ■'KriT 

;srAkr  r>KA'  CLAUSE 
I  [  IKFEKP 

.'EXTC-irK  PUP  "ELEMEal" 
LEPT-PKOCt'ljliRE-CALL 
HE  CURi-. 


rule  EL!-;''IE.jT->SPECIFICATZON 
;UECLAHE  '/AHIAHLES 
V  IH  90 
VIR  rfH 

;  CHECK  UEPE-^UEHCE  OK  "ELEHEHT" 

IK  OK.PK'insT 

GEC  HO  HEL;V 

ELSE 

Clear  so 
End 

;  -10VE  TO  NE.'I  HUFKEH 
SPLIT-bUFKEH 

;execiji>:  fop  "specification"  in  men  buffer 

LEFT-PPOCEOURE-CAuL 
.•RETURN  TiJ  PREVIOUS  BUFFER 
hack 

;GET  KELATIVE  PATH  FOR  SPECIFICATION 
;l4  RELATION  hierarchy 
niFFER  SO  HR 

;AU0  COt.TE  JTS  OF  NEW  BUFFER 
FEHGE 

;SAVK  CURRENT  RELATION 
PUT  0R  RELN 

;OEPK.ii>Ei4CE  FRO.'I  NOe  ON 
SET  UEPE'VOsr 
KE  TURN 

rule  SPECIFlCA’riON->LIT  FLDN 
rUECLAHE  VARIABLES 
VAH  liU 
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VA^i  *K 
VAK  ♦K 

••^XfJCUTb;  KLON  (■'XPST 

i<  tGHT-PPUCKOURt-CAljl. 

;SAvK  HtSHt/CS 
PUT  '<iR  TK.-'P 

par  *F  FIKLO 

;KXtCiil>:  r'OK  r,IT 

LtCFT-PPOCK(K;«t>CAMj 

.'CHrJCN  C').-tPATIHlL.ITY  liF  PKIvATlONS 

Gfjr  <10  TKvp 

S  A  1 K  s  ^  »  P 

;( FAILS  IK  iOT  SAlcI 

APPK:/I/  [ 

FIKLD  mA-IK 
C.KT  KTKLD 
JiJfJ  »K  *t: 

;  (KAILS  IK  FIELDS  LOT  SA'-IK) 
APPENDS 

;INSKRX  LITERAL 
JOIN  ’V 

;e^u  syntax  fup  clause 

APPEtiO  ] 

JSO  THAT  yP  HAS  ORIGINAL  ’VALUE 

c,Ei  "iP  temp 
FETUR'i 

filet  iDnary  entry  "ROLE"  KLD  J 

JKELAflO'V  AS  path  1;.  HltPAPCHY 

SUHSEQ  RH  AIRCRAFT 

.•FIELD  NVIE 

PUI  vT  AK  'RULE 

FErOHN 


dictionary  entry  "  rvTERCFPTOR"  LIT 
IHELATIOf!  AS  PATH  If-.  HIERARCHY 
SUrtSEO  AIRCRAFT 
.•FIELD  NAME 
POINT  ♦K  RULE 

itfALUE  IN  FORM  UF  A  STRING  RATTERN  T.O  MATCH 
POINT  ♦V  A/v  I  /.< 

HETIIKN 


The  procedures  here  are  sl'npllfied  tro'n  those  In 
query  facility,  nut  Illustrate  essentially  what  is 


an  actual 
involved  In 
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producino  an  Interinediate  query  from  an  input  query.  The 
procedures  associateu  vKith  a  basic  query  language  grammar  in 
general  viil  work-  entirely  with  pointers  relations,  fields,  or 
values,  khlcri  will  he  set  hy  proceoures  for  dictionary  entries. 
In  tnls  way,  the  same  grammar  can  oe  used  with  different 
olctlonarles;  all  tnat  is  necessary  is  for  a  dictionary  to  Icnow 
wnat  varlaMes  to  pass  information  through.  In  the  case  of  AQT, 
only  three  variaoles  will  he  of  concern:  aR  tor  a  relational 
path,  ♦(=■  for  a  field,  and  ♦'/  for  a  literal  value.  The  procedures 
tor  setting  these  variables  will  be  simple  enough  to  be  generated 
automat  leal ly  from  input  lists  describing  associations  between 
literal  values  and  fields  and  between  fields  and  relations, 

3.4  Hecocnlzinj  deoendence  between  parts  of  a  query 

The  #QT  intermediate  translator  incorporates  special 
features  for  dealing  with  linguistic  dependence  in  a  query.  The 
most  simple  kind  that  has  to  oe  considered  Is  the  imolicit  local 
aependencp  between  two  subconstituents  coming  togetner  to  form  a 
single  new  constituent;  in  the  intermediate  form  of  a  query, 
tnis  has  to  oe  maooed  into  an  explicit  dependence  path  in  a 
relational  Merarrnv  tnat  connects  different  fields.  Several 
semantic  primitives  In  aqt  help  to  facilitate  this;  one  allows  a 
path  from  the  top  of  a  hierarchy  down  to  a  given  relation  to  be 
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expressed  as  a  list  of  pointers  as  relation  natie  strims 
(oUBSEO);  one  compares  a  list  ot  strino  pointers  rfitn  another 
and  puts  at  tne  start  of  an  Intermediate  query  clause  tne  path 
sequence  of  tne  first  wnere  it  diverges  from  tne  second  (UIKEEk) ; 
and  one  compares  tvo  dorfnwara  patns  and  fails  if  tnev  differ, 
tnus  rejectinq  the  current  parse  (SA~-K). 

The  dependent  relational  oatns  qenerated  oy  these  primitives 
will  by  desion  not  oe  unamolquous  in  themselves  because  they  «ill 
be  relative  paths  reouirinq  a  context  of  interpretation.  This 
ambiouify,  however,  turns  out  to  be  useful  wnere  a  field  name  may 
be  defined  in  several  different  relations;  instead  of  listlno 
all  of  the  cases  and  tryim  to  fioure  out  whicn  is  tne  riant  one 
in  tne  intermediate  translator,  we  enter  an  amoijuous  path  and 
rely  op  intermediate  auery  resolution  in  the  target  data  base 
translator  to  cnoose  the  nroper  interpretation  ii>  the  current 
context.  This  kind  nf  postponement  is  convenient  because  the 
intermediate  translator,  navina  semantic  procedures  built  around 
strlnq  maripulation,  Is  poorly  equipped  to  make  a  correct 
decision.  The  approach  nere  allows  the  intermediate  translator 
to  reptalr  fairly  simple  while  not  compilcatlnq  intermediate  query 
resolution  all  tnat  much. 

Another  rrocessini  strateay  alonq  these  lines  is  used  in  AQf 
tor  more  alooal  sorts  of  aepenoence  in  asoects  ot  lanquaqe  like 
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pronoun  reference,  -iefinite  noun  pn 
fragmentary  queries.  -Tnese  icinus  of 
care  of  In  tbe  inter^eoiate  translate 
reoucing  tnem  into  terns  exoresslole 
langudoe.  ite  llnltea  semantic  proce 
translator  prevents  doinn  a  great 
accomplish  setrethinu  nontrivial  and  t 
orocesslno  further  do»n  the  line 
translator.  Tnis  is  in  tact  an 
translation  strategy. 


rases,  and  some  <lnd$  of 
language  usage  must  be  talcen 
r  at  least  to  the  extent  of 
•xitnin  the  AOT  intermediate 
ssinq  in  the  intermediate 
deal,  but  it  is  possible  to 
nus  simplify  the  problems  of 
in  the  target  data  base 
advantage  of  a  multi-pass 


To  tiancle  jlonti  linguistic  dependence  in  AOT,  a  number  of 
special  glooal  varlaoies  are  aefihed.  Tnese  are  like  the 
ordinary  varianles  declared  in  semantic  procedures  in  that  they 
■would  hole  sa;ne  sorts  of  information,  but  tney  are  defined 
outside  any  semantic  procedure  and  in  fact  outside  the 
interm.ediate  translator  itself  since  they  must  be  saved  between 
queries.  Tre  ulooal  variables  Keep  tracK  of  the  last  relation 
and  the  last  field  referenced  (HELn  and  FIELD  resoectlvely)  as 
well  as  of  the  relational  focus  of  a  query  as  derived  from  syntax 
aho  of  the  kinds  of  references  to  counts.  Global  variables  are 
accessible  onlv  through  the  primitives  GET  and  PUT. 


The  usaoe  of  global 
case  of  a  pronoun  or 


varlaoles  is  straightforward.  In  the 
an  information  request  like  "now  many?" 
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Where  no  relational  intorfratlon  is  given,  tnis  Is  sintply  tilled 
out  iron  the  aorronr iate  glonal  varianles  and  processing 
continues  as  tefore.  mere  is  no  attempt  to  resolve  glooal 
dependence  in  tne  sense  ot  actualiv  finding  referents,  tnough. 
This  is  left  uo  to  suoseouent  passes  in  the  target  data  base 
translator. 


J.5  Siipporf  facilities 

rne  ACT  front-end  language  processor  has  several  built-in 
features  that  simplify  tne  tas*c  ot  defining  a  guery  language  for 
a  user. 

0  Inflectional  stemnmer 

i^ords  in  a  query  language  vocabulary  may  often  appear 
with  -s,  -ed,  and  -ina  inflectional  suffixes.  AOT 
Includes  a  procedure  tnat  automatically  removes 
such  suffixes;  it  recognizes  over  500  different 
cases  ot  word  endings,  substantiailv  more 
than  similar  procedures  on  most  natural  language 
systems,  inis  means  tnat  only  root  forms  of  regular 
nouns  and  verbs  nave  to  be  entered  in  a  dictionary, 
o  Imoetlned  literals 

l>oery  words  undefined  in  a  dictionary  can  still  ne 
processed,  tnis  Is  helpful  when  a  target  data  field 
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car  tatca  a  lane  nutiher  ot  non-numeric  values;  APT 
automatically  takes  care  of  undefined  words 
cci  responilinj  to  -iata  field  values  when  the  field  is 
explicit#  and  other  cases  can  be  nandlevd  with  tne 
adoitlon  of  rules  of  orammar  tor  the  syntactic 

cateaory . 

o  Ptrino  patterns 

ACT  has  a  bullt-in  strinq  oattern  matcher  that  allows 
for  concise  interiredlate  lanquaqe  definitions  of  words 
ccrresoondlm  to  target  data  fields  or  values.  This  is 
capable  of  matcnlng  initial  substrings,  embedded  optional 
substrings,  and  a  combination  of  alternate  string 
uatterns.  It  is  especially  nelotul  tor  complex 
nultlworo  field  names  or  literal  values  that  may  appear 
in  many  different  ways. 

These  Kinds  of  features  support  a  data  case  manager  in 
setting  up  a  query  facility.  Tnis  process  is  unseen  oy  the  data 
base  user,  but  it  is  nevertheless  important  in  determining  the 
ultimate  usefulness  of  tne  guery  facility.  The  ability  for  a 
oata  base  manager  to  change  or  to  add  to  a  query  language  with  a 
minimum  of  effort  helps  greatly  in  tailoring  a  facility  to  a 
particular  set  of  users  and  in  ejctendina  the  facility  when  its 
appllcatiors  orow.  Although  this  is  not  as  convenient  as  in  some 


1 


Page  3-24 


Handling  Natural  Language  Queries 

systems  where  users  themselves  can  mold  a  query  language,  it 
should  worK  out  much  the  same  anyway,  assuming  that  query 
language  will  eventually  stabilize. 


Page  4-1 


■SKCriUN  4 

Taraet  Data  iiase  Access 


4.1  Data  access  sequences 

An  input  pjery  translated  into  intermediate  form  refers  to  a 
relational  Merarcnv  serving  as  a  logical  model  for  a  target  data 
rase.  At  this  ooint,  there  are  many  ways  to  mao  the  intermediate 
query  references  into  an  access  sequence  for  the  target  data 
base;  but  for  nortabiiltY»  it  is  convenient  to  adopt  a 
taole-orlven  scheme  along  the  lines  of  the  AQT  parser  for  input 
queries.  The  necessary  tables  for  this  can  be  made  external  to 
the  actual  code  for  a  query  facility,  iceeping  the  code 
independent  of  any  particular  data  base. 

A  correspondence  between  logical  fields  in  a  relational 
hierarchy  and  actual  fields  in  records  of  a  target  data  base  is 
easy  to  establish  in  a  table.  There  is,  however,  a  problem  in 
mapping  over  the  kinds  of  dependencies  defined  between  the 
different  fields  of  a  relational  hierarchy;  for  example,  the 
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connection  tet^een  a  ney  tleld  ano  a  non-icey  tielrt  at  different 
levels  along  a  oatn  of  relational  nierarcny.  iecause  the 
corresponding  fields  In  tne  target  data  nase  may  not  be  in  tne 
same  recoro  or  even  in  two  directly  Iin<ed  records,  tne 

generation  of  a  data  access  seguence  witn  tne  rlont  dependence 

% 

requires  a  little  wortc. 

The  oasis  for  access  seouence  generation  cones  from  two 
ooservatlons  dooot  necessary  correspondences  Between  relational 
nlerarchles  anj  target  data  oases.  First,  It  two  fields  are  in 
tne  same  relation,  then  tne  target  data  fields  most  be  on  tne 
same  record  or  on  two  records  connected  ny  a  cnaln  of  one-to-one 
linns.  second,  if  two  fields  are  in  nierarcnic a  I ly  adlacent 
relations,  then  either  the  cor resoonoing  taraet  data  fields  are 
either  in  the  same  record  or  one  is  connected  to  tne  other  by  a 
chain  of  one-to-one  or  one-to-many  lln<s.  This  all  comes  out  of 
having  set  uo  relational  nierarchles  so  that  non-<ey  fields  are 
functionally  deoendent  on  ney  fields  at  the  same  level  or  above. 

Relational  fields  that  occur  along  the  same  downward  path  In 
a  hierarchy  are  dependent,  and  so  tnere  should  oe  a  seguence  of 
trivial,  one-to-one,  and  one-to-many  J  ln<s  connecting  the  target 
data  records  with  the  corresponding  fields.  To  derive  such  a 
sequence,  we  win  begin  by  Interpreting  the  direct  record  llnKs 
of  a  taraet  data  base  in  terms  of  a  relational  hierarchy.  Tnat 
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is»  «e  wjH  t^^nK  ot  tnese  limes  not  only  as  connections  bet«»een 
flitferent  recor  i  types,  out  also  as  inicllcit  Intra-relatlonal  and 
ir.terrelatior.al  connections;  a  link  «iill  be  treated  as  a  way  of 
(povlno  ticn  one  coordinate  of  (relation,  record  tyoe)  to  another 
coordinate. 

Ttiis  *ill  all  ne  part  ot  a  logical  data  7>odel  ccnbletely 
external  to  a  taroet  -lata  base,  we  can  cnan  je  our  Interpretation 
without  charoin;  toe  target  data  Base.  In  general,  a  given 
direct  linkage  Tiav  ne  used  for  moving  oetween  several  different 
pairs  ot  (relation,  record  type)  coordinates;  and  of  course,  we 
can  always  choose  to  disregard  certain  direct  linkages  altoqetner 
witn  a  given  logical  trodel,  A  class!  fication  of  direct  record 
linkages  tor  a  relational  nierarcny  will  be  stored  in  external 
intra-relat ionai  and  intra-relatlonal  link  tapies  read  by  a 
target  data  base  fanslator. 

To  avoia  combinatorial  uroplems,  Inter-re lational  links  will 
re  detineo  so  that  tney  can  always  correspond  to  going  down  in  a 
hlerarcfy;  ana  a  notion  ot  sublevel  will  be  established  for 
intra-re lational  links  to  allow  a  similar  downward  restriction 
for  tneri’  as  weii.  Tnls  will  assure  tnat  generated  sequences  will 
be  forced  In  effect  to  move  down  paths  In  a  relational  hierareny 
ano  evertuaily  nit  bottom.  Tne  relational  hierarchy  here  models 
a  user's  rerceotion  of  access  to  stored,  data. 
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4.2  A  4-pass  access  scheme 

Interpretation  of  an  intermediate  ouery  strinq  oeqins  with 
its  conversion  Into  a  resolved  Internal  form.  rnis  involves 
eliminatior  of  anv  arroiduity  with  relation  names  in  clauses,  tne 
collection  of  field  references  tor  the  same  relations,  and  in 
case  of  an  initial  dependent  clause,  tne  merger  of  information 
from  the  intermediate  query  strinq  *ith  the  resolved  form  of  tne 
previous  query.  This  nrocess  nas  already  been  described  in 
Section  2. 

The  procedure  tor  oeneratlntj  a  data  access  sequence  from  a 
resolved  inter nedlate  query  will  oe  to  oroceed  oacKwards  from 
fields  in  the  query  as  foliowss 

o  Look  ud  eacn  reiational  field  soecifleo  in 
the  intermediate  query  and  qet  tne  record 
type  associated  witn  it,  tne  location  and 
size  of  the  data  field  in  a  record,  and  tne 
type  of  data  stored  there.  This  information 
can  he  collected  in  an  external  field 
correspondence  taole  Keyed  by  field  name  and 
relation. 

0  If  the  record  type  for  a  field  Is  directly 
accessible  in  a  target  data  base,  such  as 
through  some  hashing,  indexing  or 
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seq'iential  access  •netDoa,  tDen  we  are  done 
tor  tnat  tteld. 

0  If  a  record  tvpe  Is  not  directly  accessible, 
tneo  we  neeo  to  get  to  it  via  a  direct  linK 
tro.M  anotn-r  record  tyoe.  To  get  tnis  llnic 
we  first  looic  tor  any  Interrelational  link 
or,  if  there  is  none,  any  intra-relat ional 
lin<  tor  the  given  (relation,  record  tyoe) 
coordinate  and  then  continue  as  above  for  tne 
new  (relation,  record  tyoe)  coordinate.  If  a 
relational  hierarchy  is  set  up  correctly,  then 
there  snould  always  be  a  link  wnen  needed. 


After  apD 

lying 

this 

procedure 

tor  all  fields 

in 

an 

intermeolate  i 

uery. 

tne 

result  is 

a  branching  sequence 

of 

accesses  with  a 

str 

uct'ire 

parallelin 

g  the  dependence 

between 

fields  expressed  in  the  Intermediate  query.  Tne  structure  will 
not  be  Identical  to  the  interirediate  query,  however,  because  a 
data  relation  may  encomnass  several  different  data  record  types 
and  oitterert  relations  may  ne  defined  over  the  same  record 
types.  It  is  also  convenient  sometimes  to  Introduce  along  an 
access  sequence  sone  additional  logical  relations  not  referenced 
in  a  relational  hierarchy. 


.Each  entry  in  the  inter-  and  intra-relatlonal  link  tables 
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will  Include  an  encodlnq  of  the  actual  access  linkage  to  get  from 
one  record  tvpe  to  another;  tor  example,  nashina  a  secondary  key 
or  tollowing  a  pointer  or  stclpplng  some  offset.  There  Is  a 
potential  rroplem  of  encoding  here  in  that  there  can  oe 
aroltrarlly  nanv  tvoes  of  linkages  in  general,  out  since  only  a 
finite  numper  are  used  in  any  given  target  data  base,  our 
approach  *1111  he  to  have  a  tew  common  linkage  types  predefined 
and  allow  a  user  to  Introduce  more  exotic  tyres  oy  linking  in 
special  code  to  handle  them. 

Retrieval  of  information  with  a  oata  access  sequence  trom  an 
intermediate  query  will  ne  through  a  special  search  procedure 
built  Into  ouerv  facility.  This  will  use  the  access  sequence  to 
traverse  records  of  a  target  data  oase  making  comparisons  of 
fields  against  given  ouery  conditions  and  extracting  requested 
Inforniatlon  where  Indicated.  Tne  result  of  this  will  be  a  series 
of  index  lists  specifying  record  Instances  by  type  and  relation 
that  happen  to  matcn  the  conditions  for  an  access  sequence. 
Retention  of  relational  identifiers  as  a  distinction  in  index 
lists  is  necessary  because  record  instances  listed  under 
different  relational  headings  will  be  selected  or  relected  in 
general  by  different  criteria  and  will  call  tor  different  outout. 

Index  lists  need  to  be  saveo  because  natural  language 
queries  may  contain  pronouns  or  other  linguistic  constructions 
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that  reter  to  results  ot  a  preceding  guery.  The  idea  here  is  in 
effect  to  treat  a  aeoendent  query  of  this  sort  simply  as  a 
continuation  of  the  orevlous  query,  taxing  up  in  the  traversal  of 
a  target  oata  case  -unere  tne  other  left  off.  It  turns  out  that 
this  requires  little  to  be  added  to  the  basic  data  search  scheme 
since  oepenoence  already  must  be  handled  within  a  single  query 
anyway. 

Output  can  be  pro  luced  for  a  query  as  soon  as  a  complete  set 
of  matchlno  records  Instances  have  been  collected  for  a  data 
access  sequence.  In  the  case  of  multiple  matching  Instances  at  a 
one-to-many  linX,  our  approach  will  be  to  collect  all  of  them  at 
the  sane  tire  except  for  multiplicities  at  the  head  of  data 
access  seouences;  this  happens  to  be  a  convenient  point  to  save 
partial  results  for  a  query  when  soace  tor  index  lists  is 
limited.  As  for  the  actual  format  of  the  output,  this  comes 
naturally  cut  of  the  definition  of  relatlonai  hierarchies;  each 
downward  path  in  a  hierarchy,  and  consequently  the  corresponding 
data  access  suoseouence,  can  be  prlntea  out  as  a  third-normal 
form  relation. 

Sections  and  b  will  describe  how  the  procedures  outlined 
here  have  been  Impiemented  on  th  AOT  demonstration  system  and 
win  go  into  some  xey  problems  arising  in  them.  On  the  whole, 
nowever,  these  oroceoures  are  fairly  straightforward  for  all  they 

-/ 

i 
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ao  and  car  re  readily  put  Into  FOHTHAa.  rne  simplicity  ot  tne 
basic  scheme  is  a  distinct  advantage,  especially  in  comparison  to 
what  other  systems  have  to  do  In  order  to  implement  similar 


capaolllties 
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5.1  Generic  seconlarv  keys,  null  keys 


In  a  taruet  data  base,  certain 
several  versions,  with  some  kind 
various  versions;  for  example,  "nion 
"best  count".  Tne  keys  are  typical 
not  necessarily  unique  to  a  alven  clas 
or  may  not  oe  an  actual  target  data 
the  actual  key.  Prooer  resolution  of 
knowledge  of  hox  a  target  data  base  is 
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UD. 

It  is  advantageous  to  avolo  having  to  resolve  generic  keys 
while  parsing.  This  keens  input  query  processing  Independent  of 
anytaroet  data  base  application  and  also  simollfles  the  parsing 
procedure.  Curing  query  translation  in  Ayx,  generic  keys  are 
kept  around  as  oracketed  components  of  their  associated  field 


names  until  the  generation  of  data  access  sequences  for  tne  data 
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case.  The  keys  are  tnen  looked  up  In  a  special  external  table 
keyed  ny  relation  to  deternilne  now  they  actually  refer  to  tne 
taraet  data  base. 

Closely  relateo  to  aenerlc  keys  are  qualifiers  so  qeneral  l.n 
a  given  text  tnat  tney  carry  no  information  at  all;  for  example,. 
"Husslan"  in  a  data  base  of  Soviet  aircraft.  Tnese  null 
dualitiers  can  ne  nandieo  In  a  data  oase  dictionary  oy  assigning 
tneit.  to  a  special  syntactic  category  tnat  Is  skipped  over  In 
parsina.  vote  tnat  a  logical  ’nodel  in  selecting  a  given  subset 
of  a  taroet  data  base  for  access  may  result  in  changing  an  actual 
key  into  null  qualifier. 


5.2  Numerical  comoutatlon 

when  getting  numerical  information  from  a  target  data  base, 
a  statistical  summarv  of  values  Is  often  more  convenient  than  a 
straight  list  of  them.  Accordingly,  comprehensive  data  base 
access  facilities  usually  build  In  standard  statistical  functions 
like  mean,  standard  deviation,  maximum,  and  minimum.  In  AQT, 
such  functions  are  coraouted  oy  a  special  module  that  does  all  the 
work  of  ioentifying  a  function  oy  name,  of  collecting  the  values 
for  calculation,  and  of  displaying  the  results.  The  module  can 
oe  tailored  for  a  particular  abollcation  without  affecting  the 
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rest  of  the  code,  for  oaery  translation. 

The  Implementation  of  a  statistical  module  is 
straightforward  except  for  a  possiole  complication  with  naming. 
It  is  possible  for  field  of  a  target  data  base  to  contain  a 
statistical  function  as  part  of  its  nane;  for  example,  "maximum 
weight"  coulo  be  an  actual  stored  value.  In  this  case,  the 
target  data  base  translator  needs  to  recognize  that  no 
computation  is  necessary,  although  a  user  need  not  Know  one  way 
or  the  other. 

The  procedure  in  AQT  for  handling  function  name  components 
of  a  field  name  is  similar  to  tne  one  for  handling  generic  keys. 
To  avoid  cluttering  up  the  parser  with  Information  aoout  a  target 
data  base,  the  resolution  of  the  function  name  is  postponed  until 
the  generation  of  data  access  sequences  when  field  names  nave  to 
be  looked  up.  If  a  function  name  is  not  found  as  part  of  a  field 
name,  the  corresponding  function  will  oe  computed. 

A  general  arithmetic  capability  is  part  of  the  long  range 
•plan  tor  This  could  be  implemented  by  special  functions 
specified  in  the  intermediate  query  language  that  emulated  the 
operation  of  a  desk  calculator,  nther  computational  capabilities 
suchas  for  generating  grapnical  displays,  data  smoothing,  and 
derlv4.ng  robust  descriptive  statistics  in  the  manner  of  TuKey 
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(IIJ  are  also  nossinle. 

5.3  Arrays 

A  field  lo  a  relational  hierarchy  may  actually  correspond  to 
an  array  of  values  in  a  tarqet  data  base.  This  complicates  AQT 
data  access  beciuse  it  involves  anotner  level  of  data  extraction 
*nen  iroivldual  array  elsments  as  well  as  an  array  Itself  nave  to 
oe  manipulated.  The  problem  here  is  to  define  a  general  access 
scheme  that  is  indepenoent  of  any  target  data  base. 

The  API  approach  to  arrays  will  in  effect  be  to  translate 
the  multiplicity  of  array  elements  in  a  single  record  into  a 
multiplicity  of  virtual  records  each  with  a  single  scalar  array 
element  value.  This  is  accomplished  oy  including  an  array 
element  offset  value  in  the  Inoex  lists  of  record  instances 
matchlno  conoltions  of  a  diven  query.  The  array  offset  serves  to 
identify  tr.e  particular  array  element  associated  with  a  given 
virtual  record  instance. 

Although  this  scheme  reguires  Uniting  in  special 
user-supplied  procedures  to  compute  array  elements  offset  vaiuesr 
overall  it  is  fairly  straightforward.  The  only  serious 
restriction  is  that  an  array  field  value  in  a  relational 
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blerarcby  must  oe  the  only  fielo  of  sotie  relation  so  that  an 
array  offset  Is  unanbiouously  associateo  witn  that  field;  out 
this  is  natural  since  arrays  cynically  are  named,  divinq  iis  a  way 
to  put  it  into  a  relational  nlerarcny,  Havinq  virtual  record 
Instances  costs  only  extra  space  ir  index  lists;  no  extra  I/O  is 
needed. 


5.4  b:ill(  sis 

An  elliptical  expression  in  natural  lanauaqe  is  an 
aobreviateo  Kind  of  linguistic  usane  that  requires  expansion 
within  some  context  oefore  it  can  be  understood,  For  example, 

t^hat  is  tne  lenatn  of  tne  Flooier.' 

The  Fcxbdt? 

where  the  seconi  query  is  elliptical  and  must  he  understood  In 
context  as  "what  is  the  lengtn  of  tne  Foxoat?"  rriis  xind  ot  usage 
maxes  a  lanouage  highly  efficient,  and  so  natural  query  lamuaqe 
facilities  alnost  always  niaxe  some  attempt  to  support  it  through 
Incorporation  of  special  procedures. 

In  the  AVI  aooroach,  nowever,  no  soeciai  procedures  are 
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reaulre<i.  ^lliDsis  is  rianaled  entirely  throucn  existing 
'r.pcnan  1  Sii  s  for  resolvln-j  reference.  An  elliptical  auerv  is 
treateo  exactly  llKe  a  qoerv  contaimncj  an  anapnorlc  expression; 
in  tr.eir  irter ^lediate  for'’s,  an  elliptical  gaery  is  nenea  with' 
tne  resolved  orecertinti  ouory  to  orojuce  a  ne*  resolved  query, 
Tnl  s  ■‘dreat  ly  si-npiifies  an  A?T  query  facility. 


5.5  •cF’*  concition 


Disliinctive  conditions  in  lueries  are  inplemented  two 
'Jitterert  ways  in  ACT,  the  sl^fipier  way  is  to  allow  more  tnan  one 
value  tc  be  ciiven  in  a  tlelj  specification  of  a  query,  lettino  a 
fatten'  rafcner  cry  eacn  value  in  succession  against  a  target 
odtd  field  durim  a  data  oase  searcn.  Tnis  would  require  only 
tre  aociticn  of  a  few  rules  in  a  query  lanauaqe  grammar  and  a 
stralor  t  f  crwtir q  extension  of  tne  pattern  matcnlng  procedure  in 
ACT. 


dore  nerieral  olslunctive  conditions  In  queries,  nowever, 
must  oe  expressed  over  sets  of  clauses,  requiring  elaPoration  of 
tne  control  struct  ires  in  target  data  base  translation.  The 
arproacb  in  aCf  nere  is  to  take  advantage  of  procedures  already 
used  for  handiim  coreference.  A  series  of  clauses  expressing 
different  "Cib''  conditions  are  treated  in  tne  same  way  as  series 
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Of  depenoent  clauses  except  tnat  a  £la7  Is  set  to  allow  a 
restr icteo  search  on  failure  to  cnanqe  into  an  unrestricted 
search. 


Each  set  of  clauses 
processed  separately  i 
display  of  results  put  o 
fhls  is  only  sliahtly 
for  disjunction,  renuirl 
query  rrocessinq  and 
searchino  a  target  data 
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5,6  Purgiro  a  context 

In  processing  a  query  dependent  on  a  preceding  query,  we 
need  to  start  fro.n  tne*  record  instances  matched  py  tne  nrecedlng 
query,  but  we  nave  to  be  careful  about  wnlch  Instances  we 
actually  retain.  To  see  why  tnis  i-s  so,  we  miqnt  consider  the 
following  simple  relational  nierarcny: 

AIPCKAFT  Cnato  name!  ^ 

•  \ 

:  .  .  cnNFiGUHATlO’x  (type]  ' 

where  ATkckakt  to  COi'tFlGiJdATinw  is  one-to-many,  ana  the 
intermediate  queries  ■ 


i 

( 
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AlHfSiAF  T(y/n?)  [nato  name=F'loaqer  J 
.  Cf'f  F  ic  JHATTOM  [ ty pe=tact ical  support] 

(.) 

.  AlKCH AKT(y/pV jCuNKiGuKATlON  [tyDe=air  superiority] 

(.) 

in  tne  iirst  query,  we  qet  a  record  instance  for  COMFIGURATION 
[tyoe],  rut  we  do  not  want  to  restrict  our  search  of 
CDF'KIGiit AT  U-N  itvne]  to  this  instance  in  the  second  query,  for 
then  no  tratch  will  ever  ne  possihle. 

The  rule  nere  is  tnat  record  instances  correspondinq  to  a 
relation  in  a  riierarcny  should  oe  purged  it  there  are  query 
markers  alonn  tne  nlerarchical  path  for  tne  relation  and  if  these 
are  all  ahove  it.  This  is  a  selective  purging  distinct  from  that 
involved  in  resettina  a  context  uoon  getting  an  independent 
query.  It  has  to  ne  done  after  results  are  displayed,  but  before 
the  resolveo  internediate  form  of  the  preceding  query  is  lost. 
The  decision  to  reset  a  context  in  general  can  come  only  after 
the  precedino  intermeoiate  query  has  been  tierged  with  the  new 
query. 

b.7  Conversational  postulates  qovernlna  responses 
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Althoupr  -re  can  always  oive  a  data  nase  user  exactly  what 
was  asked  for  by  Interpretlna  queries  literally,  tnis  nay  not 
actually  be  what  the  user  wanted.  in  ordinary  speecn  amonq 
people,  literalness  is  never  strictly  enforced  because  we  can 
usually  tell  when  a  literal  resoonse  is  inappropriate  oecause  we 
know  what  Is  typically  expected  in  a  diven  situation;  for 
exaiiiple,  app-ooriate  responses  to  tne  question  "May  i  asK  your 
name,  please?"  include  "r'-o"  and  "John  smith",  but  not  a  simple 
"Yes".  These  Kinds  of  expectations  can  qet  extremely  complex  for 
orolnary  speech,  nut  in  the  narrow  context  of  interactive  data 
base  access,  it  is  fairly  easy  to  ouild  some  of  tnem  into  query 
interpretation  to  make  it  more  nospitaole  to  a  user. 

In  AOl,  we  can  in  fact  do  some  things  witnout  navlnq  an 
elaborate  node!  of  exoectatlons  for  a  data  nase  user. 

o  In  yes/no  or  how-many  queries,  a  user  will  frequently 
want  a  full  retrieval  of  information  ratner  a  simple 
straldht  answer;  for  example,  in 

”Do  any  fiqnters  carry  the  ATOLL  missiles?" 
it  is  likely  that  the  deslanations  of  the  fiqnters  are 
also  wanted,  we  can  in  aeneral  tell  tor  sure  when  a 
;  full  retrieval  is  called  for,  but  we  can  easily  enouqn 

prompt  a  user  after  makino  a  straight  answer.  Although 
this  makes  a  user  oo  a  bit  more,  it  saves  having  to 

i 

I 

r 

4 

I 
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re-enter  a  query  If  tne  full  retrieval  mas  wanted, 
o  ^ren  tne  nonber  of  '^'atcrung  record  instances  in  a  target 
data  case  fails  to  equal  a  count  specified  in  a  query, 
it  pays  to  qo  tnrougn  a  retrieval  anyway  so  as  not  to 
waste  wor<  already  done,  for  example,  in  tne  query 
"Are  tnere  two  aircraft  carrying  tne  ACRID?" 
we  wouio  want  to  respond  even  if  there  was  only  one 
aircraft . 

0  (in  full  retrievals  wicn  irany  matched  records,  we  will 
ask.  tne  user  whetner  a  coir.plete  listing  is  really 
oeslraole.  A  user  typically  will  not  want  voluminous 
output  at  a  terminal. 

Rroceccres  for  ellipsis  can  also  be  mentioned  here. 

Tne  rule  in  a^t  here  is  always  to  give  a  user  the  benefit  of 
the  doubt  Ir.  a  situation,  wone  of  the  features  above  involve  any 
theoretical  clf f Icultles,  and  ail  are  easy  to  implement.  They 
are  imrortant,  nowever,  in  tnat  they  maxe  a  query  facility  easier 
to  work  with  but  vet  they  are  an  aspect  of  natural  language  often 
neglected  in  so-cailed  natural  language  systems. 

b.d  fjn-llrie  oata  nase  documentation 
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with  natur-il  lanqudqe,  it  is  possible  for  a  user  to  enter  an 
intelligible  query  witn  no  references  to  fields  either  as  search 
conditions  or  as  requested  information;  for  example,  "Tell  me 
about  aircraft.",  where  "aircraft"  is  a  relation  name  in  a 
hierarchy.  This  query  could  be  processed  lixe  other  types  of 
query,  but  tne  results  would  prooably  not  be  wnat  the  user 
wanted;  the  target  data  base  interpreter  would  simply  go  through 
the  entire  data  base  and  return  all  the  mandatory  Key  fields 
above  the  point  in  a  relational  nierarchy  marxed  by  the  input 
query.  This  is  a  drastic  Xing  of  information  request  even  tor 
fairly  small  data  bases,  and  or.  the  whole,  it  seems  reasonable  to 
allow  a  user  to  make  such  a  request  only  in  an  explicit  way. 

On  tne  otner  hand,  we  oo  not  want  to  disregard  a  query 
without  fields  entirely  or  to  print  on  diagnostic  message  because 
the  user  probably  entered  the  duery  in  good  faith,  given  that 
data  case  structure  Js  assumed  to  oe  transparent.  A  reasonaole 
interbretatlon  of  a  genera'  query  wicnout  field  references  is 
that  it.  is  actually  a  request  for  general  information  about  a 
data  base  itself  rather  than  for  a  complete  enumeration  of  the 
data  base.  In  tnis  way,  queries  of  this  type  turn  out  to  be  a 
convenient  way  to  Imoleraent  on-line  aocumentat ion  tor  a  data  base 
or  at  least  for  a  user's  logical  model  of  the  data  base. 


Because  a  query  without  flelg  references  marks  a  relation 
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6.1  Purposes 

The  ACT  demonstration  system  was  Implemented  to  snow  that  an 
effective  natural  lanouaqe  query  facility  could  be  built  around 
the  simple  notion  of  a  relational  hierarchy.  The  basic  AQT 
algorithms  themselves  were  straightforward  enough  so  that  we 
could  have  kept  to  presenting  a  case  for  them  on  paper»  but  the 
immediate  reality  of  the  demonstration  system  is  much  more 
compelllno,  esoecially  for  tne  potential  users  of  a  natural 
language  ouerv  facility.  Altnougn  the  demonstration  system 
represents  only  a  fragment  of  a  full  query  facilltyr  it  shows 
what  can  he  accomplished  even  on  a  relatively  small  machine  liice 
the  DKC  PIF-ll/TO. 

The  den onstration  system  also  served  as  a  major  development 
tool  for  the  aesign  of  a  query  facility.  v\ie  have  built  several 
different  versions  with  extensive  instrumentation  for  experiments 
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wltn  various  asoects  of  query  translation.  Almost  all  work  was 
3one  in  witn  a  KLtCS  oreprocessor  so  as  to  approximate 
the  conriitior.s  unier  wnicn  a  query  facility  could  eventually  be 
implemented.  Tnis  uave  us  an  idea  of  the  amount  of  computation 
involveo  in  query  translation  and  the  amount  of  space  required 
for  it.  A  DKC  r'Pt'-ll/70  oroveo  to  oe  adequate  for  an 
Implementation,  tnoudh  careful  organization  of  the  demonstration 
system  was  reguireo  for  it  to  run  witnin  a  16-bit  address  space. 


►e  rave  derived  most  of  the  basic  data  and  control 
structures  ot  a  natural  lanquaqe  query  facility  through  evolution 
of  tne  oen  oristratlon  system.  Here,  we  shall  describe  the 
demonstratlcn  system  Itself  as  currently  implemented  and  move  on 
from  this  to  a  discussion  of  now  eventually  to  oulld  a  full 
prototype  query  facility. 


6.2  basic  structures 


Tncre  are  two  categories  ot  data  structures  defined  in  AQT; 
internal  list  structures  produced  as  intermediate  results  durlnq 
tne  various  stages  of  query  translation,  and  external  tables 
supplleo  by  a  data  base  administrator  to  define  a  logical  model 
and  its  correspondence  to  a  target  data  base.  A  description  of 
these  categories  of  data  structures  fairly  well  characterizes  how 
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AQT  works#  since  tne-  algorithms  ooeratlna  on  these  structures  are 
relatively  straiqnttorward. 

6.2.1 


The  principal  Internal  data  structures  of  AOT  are  the  (1) 
the  parse  tree  for  an  input  auery,  (2)  the  resolved  intermediate 
query  expressed  also  as  a  tree.  (3)  the  data  access  sequence  for 
target  data  records,  (4)  the  Index  lists  of  record  instances 
matchino  corditlons  of  a  query,  and  (5)  the  lists  of  target  data 
fields  explicitly  or  Impiicitlv  requested  for  output  in  a  query. 

The  parse  tree  for  an  input  query  is  a  standard  type  of 
phrase-structure  description  consisting  basically  of  binary 
subtrees.  The  subtrees  are  built  up  of  ohrase  nodes  of  the 
following  form: 

1  index  of  the  rule'of  grammar  aeneratlnq  a  ohrase 

2  syntactic  category  of  phrase 

3  starting  position  of  phrase  is  query 

4  pointer  to  left  descendant  phrase  node  list 

5  point  to  right  descendant  list,  if  any 

6  semantic  plausibility  rating  of  phrase 

7  encoded  usage  count 


8  syntactic  features 
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y  semantic  features 
10,  11  miscellaneous  oolnter  llnKs 
In  tne  nemonstratlon  systen,  each  of  tne  aoove  no'le  elements  Is  a 
single  nyte  long  exceot  for  tne  rule  index,  which  is  two  bytes 
long.  A  descendant  node  list  will  contain  a  single  node  except 
in  case  ot  aioiguity,  when  it  *111  more  generally  contain 
xultlole  phrase  nodes  of  the  same  syntactic  category  and 
syntactic  and  semantic  features,  generated  from  different  rules 
of  crarrar.  This  scheme  localizes  amDioulty  as  long  as  possible 
in  a  pnrase-structure  description  of  an  input  guery. 

The  rarse  tree  defines  an  execution  seguence  for  semantic 
procedures  associated  with  ruies  of  grammar.  The  result  of  this 
Is  an  intermediate  duery  expressed  as  a  string.  The  intermediate 
duery  string  is  first  printed  at  a  user  terminal  as  a  checx; 
then  it  Is  passed  to  the  target  data  base  translator,  where  it  is 
converted  into  a  resolved  form  with  all  relation  names  replaced 
by  explicit  references  to  a  relational  hierarchy  and  all 
references  to  fields  of  relation  collected  together. 

A  resolved  intermediate  guery  is  a  tree  of  linKed  nodes 
havlno  the  following  format; 

1  relation  id  number 

2  ancestor  llnK 


descendant  iinic 
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4  Sibling  link 

5  count  specification 

6  encoded  query  mar<ings 

7  pointer  to  field  list 

8  type  of  link  from  ancestor 

An  element  of  a  field  list  nas  the  format: 

1  pointer  to  field  name 

?  length  of  field  name 

3  pointer  to  value  specification 

4  lenatn  of  value  specif icatlon 

5  link  to  next  element 

In  a  fOFTPAN  implementation,  each  item  aoove  *oJld  be  an 
array  of  Integers.  Roth  links  and  pointers  would  oe  array 
indices;  null  links  and  pointers  would  ne  a  zero  value.  Fiela 
names  and  value  specifications  will  be  character  strings  in  a 
byte  array. 

The  resolved  intermediate  form  of  the  preceding  query  is 
used  as  a  context  of  interpretation  when  the  current  gury  is 
dependent  involving  anaphoric  reference  or  ellipsis.  The  basic 
procedure  for  resolving  an  intermediate  query  is  to  process  a 
clause  at  a  time,  appending  the  results  to  that  of  preceding 
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Clauses.  It  any;  tr\e  generalization  for  anaphoric  reference  or 
ellipsis  Is  essentially  to  taKe  the  previous  query  In  resolved 
for!"  as  the  startlnn  point  for  processing  the  first  clause  of  a 
depenoent  query. 

FroJr  a  resolved  inter 'mediate  query,  we  next  generate  a 
target  data  record  access  sequence,  describing  the  order  In  which 
we  will  read  in  recoro  Instances  froni  a  target  data  oase  and  maKe 
ccnparlsors  aoalnst  data  fields. 

L'ata  access  sequences  are  generated  as  tree  structures  with 
nodes  as  follows: 

1  data  base  record  type 
/  relation  Id  nu.f,Der 

3  ancestor  llnK 

4  type  of  record  linkage 

5  link  field  offset  In  preceding  record 

fe  link  field  lenqtn 

7  units  for  record  data  field 
jf  type  of  record  data  field 
9  data  field  offset  In  record 

10  data  field  length 

11  count  specif Icatlon 

1?  encoded  query  markings 

13  pointer  to  oreolcate  for  data  field 
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14  pointer  to  list  ot  in^tcMm  record  instances 

15  descendant  ItnK 

16  siPllnj  lin< 


In  tOPlPAJ,  tnls  woild  oe  an  Intoyer  array.  Linxs  and 
pointers  would  oe  array  indices,  with  null  value  of  0. 

AOT  uses  a  aata  access  se  vience  for  the  retrieval  of  record 
Instances  froti  a  tariet  data  oase.  Those  record  instances 
matching  conditions  specified  in  tne  access  senuence  are  saved  on 
index  lists.  rne  nead  of  an  inoex  list  nas  the  following  tortiat: 

1  target  data  oase  record  type 

2  relation  identifier 

3  count  of  matcniny  record  instances 

4  pointer  to  first  instance 

Pecoro  instances  are  chained  together  in  a  list  structure 
having  nodes  with  tne  following  format: 

1  record  number  for  instance 

?  pointer  to  predecessor  instance  along  data  access  sequence 

3  pointer  to  next  instance  on  index  list 

4  bacVr  pointer  to  index  list  neal 

5  array  element  offset 
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The  Key  point  to  note  nere  Is  tnat  separate  index  lists  for 
each  rtifterent  relation  is  Keot  tor  any  record  type.  Both  Index 
list  neaos  ar.o  index  list  no<ies  are  oetined  as  integer  arrays, 
Tne  aen or  St  rat  ion  system  Keens  all  inoex  lists  in  main  memory;  a 
prototyre  ouery  facility  «oula  tnem  out  pleceaise  onto  secondary 
storage  tor  eacn  iteration  tnrougn  a  lata  access  sequence. 

dree  t,e  rave  a  full  set  of  ti.atcnlno  target  data  record 
instances  lor  a  data  access  sequence,  we  need  to  extract  the 
irtornation  to  ne  returned  in  response  to  a  query.  This  is 
descriren  tnrojin  a  reouireo  output  list  associated  with  Index 
lists  accoroin  to  record  type  ano  relational  identifier;  the 
list  Is  derived  fro.n  tne  field  name  references  of  the  original 
inrut  oueiv  anu  from  >  taole  of  mandatory  fields  tor  output 
enumerated  ny  recoro  tvoe  Plus  relational  identifier.  Uutput 
list  nodes  »ill  have  tne  following  format: 

i  cyte  offset  of  requested  tiela  in  taroet  data  record 

i  ryte  lenoth  of  field 

3  pointer  to  field  name,  if  any,  in  oriainai  query 

4  lenqtn  of  fleH  name 

5  oaia  tyoe  of  field 

6  nolnter  to  next  required  output  list  element  •' 

7  pointer  to  function,  it  any,  to  oe  computed  on  field 


This  is  defined  as  an  integer  array 
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output  Is  comoosep  starting  «iitn  a  record  Instance 
corresponding  to  an  endnolnt  in  a  data  access  sequence.  «e  men 
toilow  pack  the  cnaln  of  predecessor  record  instances,  extracting 
required  fields  alono  the  wav.  Results  are  printed  as  a  row  of  a 
Tultl-coiuer  tanie,  going  frotp  rlgnt  to  lett  in  order  of 
extraction.  since  following  predecessor  linics  corresoonds  to 
going  upwaro  in  relational  hierarchy,  this  ends  uo  with  more 
general  fields  auoearino  at  tne  left. 


6.2.;i 


To  drive  the  query  translation  process,  we  will  nave  various 
tables  oescrlolng  the  syntax  and  vocaoulary  of  an  input  query 
language  and  tne  structure  of  tne  target  data  base  pertinent  to  a 
user.  These  tables  are  i-moleaiented  as  external  files  on  the  AOT 
deuionstratlor.  svste'u  for  maximum  flexioillty,  out  for  speed,  they 
could  be  linked  directly  witn  tne  code  of  a  guery  facility. 
There  are  eight  principal  ones  altogetner  in  AyT. 


(1)  orammir  taole 


syntactic  rules  of  tne  form  x->Y  z  are  reoresented  as  a  oyte 


array 
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1  syntactic  cate<jory  X 


I  teatures  to  oe  set  on  eratino  pnrase  ^itn  rule 


3  syntactic  cateoorv  i 


A  usaoe  cojnt 


S  positive  orecon-iit ions  on  X  features 


6  ana  relative  oreconoltlons 


I  rositive  nreconnltions  on  z  features 


and  neoatlve  nreconditlons 


and  syntactic  rules  of  tMe  form  x  ->  also  as  a  byte  array 


1  syntactic  category  X 


y  features  to  oe  set  on  aenerating  nnrase  witn  rule 


3  positive  preconditions  on  a  features 


4  and  r.eqative  preconditions  Mules  X->Y  Z  are  stored 
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lists  accorolm  to  syntactic  catecjory  y.  holes  K~>'>  are  stored 
on  lists  according;  to  syntactic  category  Preconditions  apoly 
to  tne  teatures  of  onrases  neinj  comeined  tnroogn  a  role  of 
grammar  to  generate  a  ne*  ohrase.  Section  2,i  on  oarsing 
describes  these  matters  in  more  detail. 

(2)  dictionary  tanle 

vocabulary  soeclflc  to  a  target  data  oase  will  oe  icept  in  an 

external  dictionary.  An  entry  win  nave  the  form; 

1  wore  string 

2  syntactic  category  of  worg 

3  syntactic  features  to  be  set  tor  word  as  a  pnrase 

A  special  semantic  flags 

5  special  semantic  flags 

6  rath  in  relational  hierarchy  expressed  as  string 


7  field  name  string,  it  any 


Page  6-12 

A  De'npnstratlon  systen. 


S  literal  valaee  string,  if  any  A  word  string  will  have  a 
fixed  length  of  24  cnaracters,  i^ath,  field  ana  value  strings 
will  be  variable  lemtn  witn  a  final  nellmlter,  having  combined 
length  of  132  cnaracters.  ah  otner  fields  will  be  a  single 
byte  long. 

(3)  relational  moiei 

ihis  table  oescribes  the  structure  of  a  relational 
nlerarcry,  the  relation  names  associated  with  them,  and  tne 
default  record  tyoe  for  eacn  relation.  Taole  entries  have  the 
format ; 

1  relation  name  string 


7  default  record  tyoe 

3  index  of  next  relation  up  in  nierarcny 

4  rnultipllcity  of  hierarchical  linKaoe  A  relation  name  Is  a 
fixed  lenoth  string  of  IS  cnaracters.  The  remaining  fields  are 
inteqers. 


(4)  field  correspondence  table 
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This  maps  a  field  name  tor  a  qiven  relation  into  an  actual 
data  tielo  ot  a  taroet  data  oase  record.  Kacn  tanle  entry  has 
the  format; 

1  field  name  strim 

I  relation  index 

3  taroet  data  record  type 

4  type  ot  data  in  field 

5  offset  of  field  In  target  data  entry 

6  length  of  field 

A  tielo  name  is  a  fixed  length  string  of  4o  characters.  All 
other  fields  age  integer  values. 

(b)  generic  secondary  Keys 

Vnhen  a  generic  key  corresponds  to  an  actual  target-  data 
value,  it  is  listen  in  tnls  table  under  a  qiven  relation  index. 
If  not  listed,  it  must  be  part  ot  a  field  name.  The  format  of  a 


table  entry  is 
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1  oeneric  Key  string 

2  value  string 

3  relation  inuex 

4  tarcet  data  record  type 

5  offset  ot  field  In  taroet  record 

b  lencitti  ot  field 

Tr.e  vey  and  value  strings  nave  a  fixed  lengtn  of  12 
cnaracters,  rne  value  string  is  suDstltuted  for  the  Key  upon  a 
mater..  All  otner  components  of  an  entry  are  integers. 

(f)  relational  linK  taoles 

me  Inter-relational  and  intra-reiational  llnK  tables  will 
have  entries  of  the  sa.me  format: 

1  present  record  type 

'/  oresent  relation  in.dex 
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3  next  record  type  ooino  oactcwar  js 

fk  next  relation  Index/sublevel 

5  encodlnj  of  ilnkaoe  type 

6  offset  of  linkaqe  area  in  nextt  record  type 

7  size  of  linkage  area  A  potential  pronien  nere  is  tne 
encoding  of  linkage  types,  since  there  can  ne  arbitrarily  many  of 
these  in  general.  Our  aoproacn  will  oe  to  have  certain  common 
linkage  types  oredefined  in  a  query  facility  and  to  allow  a  user 
to  define  more  exotic  types  py  linking  in  special  cooe  to  handle 
them.  All  other  components  of  an  entry  are  integers.  Sublevels 
are  defined  only  for  Intra-relational  links,  taking  tne  Place  of 
the  next  relation  index. 

(7)  record  access 

A  record  access  table  describes  now  to  gain  access  to  target 
data  records  of  a  given  type.  Table  entries  have  the  following 
format: 


i  record  access  metnod 
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2  size  ot  record  In  oytes 

3  file  nene  strlnq 

In  the  demonstration  only  standard  FORTKAN  T/0  Is  assumed, 
restricting  posslole  access  methods  to  sequential  or  direct 
encoded  as  a  simle  ascii  cnaracter.  A  file  name  is  a  22 
character  fixed  length  striho.  The  record  size  Is  an  Integer 
value. 


(R)  mandatory  fields 

This  tanle  lists  record  (cey  Information  that  should  always 
be  orinted  to  aid  a  user  in  Interpreting  output  values.  Table 
entries  are  Integer  arrays 

1  taraet  data  record  type 

2  relation  Index 

3  Key  field  offset  in  target  record 

4  key  field  length  Mandatory  fields  apply  only  to  record 
type  and  relation  index  combinations  occurring  before  explicitly 
requested  information  in  a  data  access  sequence. 
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6,3  System  cont lauration 

The  Ayl  deTionstration  system  In  its  RSX-lli'i  imoleraentation 
is  organized  into  five  passes,  each  being  a  separate  overlay. 
The  processing  of  any  query  proceeds  sequentially  through  all  the 
passes.  The  first  oass  contains  tne  AOr  intermediate  translator 
comprising  a  syntax-driven  query  parser  along  with  a  query 
language  grammar;  this  reads  a  query  in  tnolisn  form  and 
rewrites  it  in  intermediate  form  still  as  a  string.  The 
intermediate  form  is  printed  for  inspection,  and  if  approved,  it 
is  passed  onto  the  largest  data  base  translator  comorislm  the 
remainino  tour  passes.  These  four  passes  successively  carry  out 
the  work  Of; 

1  converting  an  Intermediate  query  string  into  a  resolved 
intermediate  query  with  dependence  on  preceding 
queries  made  explicit, 

'I  generating  a  target  data  base  access  sequence  from  the 
resolved  intermediate  query  and  from  various 
translation  taoles 

3  traversing  tne  data  base  access  sequence  and  retrieving 

record  instances  that  match  conditions  along  the 
access  sequence 

4  deriving  a  format  for  output  and  printing  out  fields 

requested  from  matcned  record  instances. 
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Kach  ot  tiie  five  passes  Is  essentially  the  execution  of  a 
single  prlncloal  algorithm.  The  one  tor  the  first  oass  of 
parsing  ano  Intermediate  translation  has  already  been  described 
In  detail  in  Section  3.  Here,  we  shall  go  into  the  algorithms 
for  tne  four  passes  ot  tne  target  data  base  translator.  Unlllce 
the  very  general  algorithm  ot  tne  first  pass,  wnlcn  can  be 
applleo  to  a  wide  variety  of  problems,  these  are  specific  to  AOT 
and  ir  fact  constitute  the  neart  ot  AOT.  Most  ot  the  AOT  effort 
was  devoteo  to  their  development. 


0.3.1 


The  algorithm  tor  resolving  intermediate  queries  Is  quite 
simple,  consisting  mainly  of  an  inner  loop  and  an  outer  loop. 
The  overall  structure  is  as  follows; 

Step  1  If  a  query  is  dependent,  start  from  the  resolved 
Intermediate  form  ot  tne  preceding  query; 
otherwise,  discard  the  preceding  results  and 
start  anew. 

Step  2  Cet  successive  clauses  of  the  current  query  until 
an  end  marx  Is  reached. 

btep  2.1  Kxtract  successive  toxens  from  a  clause  until 


exhausted 
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step  2.1.1  For  the  case  of  tne  totcen  oelng 

1  a  relation  naine,  loolc  it  up  in  the  relation  name 

table  and  try  to  find  a  place  for  it  in 
the  resolved  intermediate  query 
Where  orocessim  left  off  last. 

It  no  place  is  found  and  we  are  at  tne 
start  of  a  dependent  clause,  qo  up  a 
level  in  the  resolved  intermediate 
query  and  try  again,  wnen  a  place 
is  found,  allocate  a  new  node  if  tnere  is 
none  already. 

2  a  query  marie,  encode  it  and  store  it  at  tne 

current  Place  in  the  resolved 
intermediate  query 

3  a  field  specif ication,  split  it  up  into  its  field 
name  ano  its  logical  condition  and  store  a  linK 
to  these  at  the  current  place  in  the  resolved 

intermediate  query. 

4  exit  with  an  error  if  tne  above  fails 
Step  3  Apply  tne  criteria  of  Section  2.2  to 

Determine  whether  to  retain  target  data  record 
Instances  from  the  preceding  query. 
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6.3.2 

i 

The  alqorltnm  tor  access  sequence  veneration  consists  of  an 
Inner  ard  outer  loop  wicn  an  Iterative  suoprocedure : 

step  1  Scan  the  nodes  of  a  resolved  intermediate  query  In 
order  of  allocation  (i.e.  straiont  interatlon  with 
no  attempt  at  a  tree  traversal). 

Step  i.l  if  there  are  field  references  for  a  node,  then  do 
for  each  field. 

Step  1.1.1  Look  up  the  field  name  in  the  field  correspondence 
table  to  get  the  record  type  associated  with  the 
name  and  the  current  relation. 

Step  1.1.2  Allocate  a  new  acces  sequence  none  for  the  field. 

Step  1.1.3  Look  up  the  current  relation  and  record  type  first 
in  the  inter-relation  link  table,  or  it  this  fails. 

In  the  intra-relatlon  link  table.  Get  the  prede¬ 
cessor  record  type  and  relation  along  an  access 
sequence. 

Step  1.1.4  If  there  is  already  an  access  sequence  node  with  the 
same  record  type  and  relation  as  the  new  node,  append 
the  new  node  after  it  with  a  trivial  link.  Otherwise, 
if  there  is  already  a  node  of  the  predecessor  record 
type  and  relation,  append  the  new  node  after  it  with 
the  link  type  from  tne  link  table. 
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otnerwise.  It  toe  ne«  node  can  start  an  access 
sequence,  ado  It  to  tne  list  ot  starting  nodes. 
iitner«ise,  allocate  a  nreoecessor  node,  llnK  the 
current  node  to  it,  and  repeat  this  step  with  the 
new  predecessor  i>ode. 

5ter  l.M  It  there  are  no  flela  references  for  a  relation  with 
a  querv  nar*c,  loo<  uo  the  default  record  type  for  it, 
aiircate  a  node  will  a  null  field,  and  proceed  from 
1.11  as  with  an  actual  field. 

Step  2  iiotlrlze  the  data  access  sequence  so  that  nodes  of  the 
sa-^e  record  type  and  relation  as  a  predecessor 

node  a.-e  listed  first  as  those  coming  after  it. 

Tne  access  sequence  oenerateo  oy  this  procedure  is  in  the  form  of 
a  forest  of  trees. 

6. 1.3 

The  search  and  retrieval  pass  ot  AQf  has  tne  most  complex  of 
all  the  aloorlthms  in  AOT.  The  procedure  can  oe  bro<en  into  two 
pieces:  a  rart  for  oroceedino  down  an  access  sequence,  and  a 
part  for  racKinn  up  along  an  access  sequence  on  hitting  an 
endpoint  or  exhausting  all  oossioilltles  for  satisfying  a 


I 

i 
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condition  rf  an  access  sequence. 


The  "down"  part  Is  as  follows; 


Step 

1 

Read  tne  next 

target  data  record  of 

tne  type 

specified  in 

tne  current  node  of  an 

access 

sequence.  Oo 

up  on  failure. 

Step 

2 

tf  tneir  is  a 

field  condition,  comoa 

re  it 

aoalMst  the  oata  record.  Uo  up  on  failure, 
step  3  f)n  a  •natch,  allocate  a  record  instance  node 

if  doinq  an  unrestricted  search,  not  starting 
from  instances  collected  previously. 

Step  4  CiO  up  upon  reachino  the  ena  of  an  access 

sequence,  otherwise,  save  the  current 
record  Instance  am  go  down,  starting  over 
at  Steo  1. 

The  "up"  part  is  as  foilo'vs; 

Step  1  If  there  is  a  maten  for  the  access  sequence 

returned  from. 

Step  1.1  Increment  the  count  of  matches  for  tne 
current  point  in  tne  sequence 
Step  1.2  If  tne  searen  is  unrestricted,  linK  in  the 

record  instance  tor  the  current  place  in  tne 
access  sequence. 


Step  l.i 


If  the  record  instance  is  one  of  a  nultiple 
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sett  uet  the  next  one  and  go  aown. 


Step  la 


If  there  is  no  match. 


Step  la.l  Porge  tne  record  instance  at  the  current  point 
in  tne  access  sequence 

Step  la, 2  If  tne  record  instance  is  one  of  a  multiple 
set,  get  tne  next  one  and  qo  don'n. 

Step  la.l  (JCherwise,  set  the  ir.atcn  flag  if  any  record 
instances  at  all  are  still  matched  at  tne 
current  point  in  tne  access  sequence. 


step  2 


.iacK  up  in  the  access  sequence 


Step  3 


It  coming  from  a  match  and  tnere  are  access 


sequences  starting  from  the  current  point,  go 
do'vn  the  next  one. 


Step  4 


If  at  the  beginning  of  the  access  sequence,  the 


procedure  is  finished.  Otherwise  go  Pack  to  Step  1. 


This  procedure  starts  at  the  oeginnlng  of  an  access 
sequence,  going  aown.  A  searcn  is  restricted  it  there  is  already 
an  index  list  for  a  given  record  type  and  relation;  note  that 
index  lists  can  be  saved  from  a  oreceding  query  In  the  case  of 
co-reference. 


6.3.4 
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Tne  tcrfrdtting  printing  algoritnni  is  as  follows; 

1  it  this  is  a  juery  *ltnojt  soecified  fields, 

oriiit  out  odta  case  oocumentation  and  quit, 
ntrer'*' 1  se ,  scan  tne  data  access  sequence  to 
iter  1.1  'let  all  enoroints  of  an  access  sequence. 

Step  1.2  Jet  all  querv  marKers  and  llelos  for  which 

cutout  IS  requested. 

Ster  1.3  Verity  tnat  there  are  ttatchlnq  record  instances 
tor  reauesten  fields. 

iter  2  If  there  are  no  requested  fields  and  it  Is  not 

a  ves/no  query,  quit  with  an  error  message. 

Step  3  If  it  is  a  yes/no  or  a  now-many  query,  respond 

accorclnq  to  matching  record  instances  and 
nromot  tne  user  for  full  output  if  there  were 
matches . 

step  ia  (Jther«lse,  format  and  print  full  output  as 

described  in  Section  4.2  if  there  were  matches, 
step  4  Delete  record  instances  from  index  lists  if 

tney  correspond  only  to  points  of  an  access 
sequence  after  a  query  mar<. 

f>.4  Setting  uo  a  data  case 

io  test  Ajr,  we  out  together  a  Soviet  tighter  aircraft  data 
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base  alona  tne  Xlnes  of  a  possible  inDie^ientation  for  an  SET 
intelligence  aoollcatlon*  tne  cnolce  of  suoject  *(as  influenced 
by  an  earlier  effort  to  nrinj  ur  a  si-nilar  data  base  on  the  dEL 
system,  but  our  basic  aporoacn  was  oifferent.  ^e  deliberately 
avoided  trying  to  construct  tne  oata  base  to  fit  i'jr;  tne  design 
was  done  inoebennent  lY  by  a  co-*oricer  untaTillar  witn  tne 
wor<inqs  of  ACT. 

The  test  data  base  currently  contains  Inf oriration  about  29 
Soviet  figfters  collected  from  open  sources  into  four  basic 
record  types,  c'or  the  most  oart,  tne  information  consists  of 
aircraft  attributes  such  as  wino  span,  fuselage  length,  and  empty 
weignt  alono  wltn  <eys  such  as  service  name  and  NATO  name;  tnese 
were  implemented  as  slmolc  fields  of  a  sinole  record  type  Keyed 
by  aircraft  and  presented  no  major  problems  in  duery  translation. 
Other  types  of  lata  had  much  miore  co..'p1px  structure,  nowever,  and 
presented  a  ri'alor  challenge. 

Maximun  soeeo  versus  altitude  information  nad  been  generated 
nypotnetlca] ly  for  aircraft  oy  fitting  a  simple  single-maxima 
approximating  curve  to  tne  Known  maximum  speed,  tne  altitude  at 
whion  maxlnum  soeed  *as  attained,  and  the  service  celling.  By 
taxing  points  at  altituoes  at  sea  level  and  up  by  increments  ot 
10,000  feet,  we  Obtained  a  speed  profile  of  the  aircraft  as  an 
array  of  mach  numbers.  The  array  was  fixed  with  a  size  of  11 
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nuitbers,  nut  nany  aircraft  vouia  nave  fewer  actual  values.  In 
the  test  fiata  nase,  tne  array  tor  an  aircraft  was  stored  in  a 
sinale  recorn  tvoe  linKed  oy  a  oointer  from  tne  main  aircraft 
record  type. 

ine  arnar.ent  conf lourat ioas  tor  an  aircraft  were  lists  of 
tne  auanrlties  of  weanons  tnat  midnt  oe  carried  on  a  mission. 
Ine  nuiioer  of  configurations  coulo  oe  different  for  each 
aircraft,  and  so  could  tne  numner  of  types  of  weapons  for  each 
con t iqurat 1  on .  necause  weapons  tended  to  oe  common  to  several 
conf iquratiors  of  an  aircraft,  tne  lists  of  weapons  fcr  an 
aircraft  were  meroed  intot  a  tree  structure  to  save  space;  a 
downward  rath  in  a  tree  would  represent  a  single  onf iguration, 
free  nooes  were  anotner  record  type,  and  weapons  data  were 
collecfeo  Into  a  tourtn  record  type  to  avoid  duplicating 
intormatior  In  tne  tree;  pointers  to  these  records  were  stored 
in  tree  roces  alona  with  the  associated  counts. 
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itie  relations  nere  were  cnosen  Because  tney  are  useful  in 
cateqorlziro  tne  data  in  the  soviet  aircraft  data  case.  We  also 
found  it  convenient  to  define  some  hidden  relations  not  appearing 
in  a  hierarchy  but  occurrina  in  access  sequences  to  establish 


! 

l 

i 


Page  6-28 


A  Demonstration  Systen 

alternate  paths  navlno  iifterent  manaatory  fields  for  output; 
this  Is  is  used  in  orintlnci  armament  configurations  Csee  Appendix 
ihese  Mmen  relations,  however,  are  not  actually  part  of  a 
logical  nooel. 
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appropriate  relations  in  tne  logical  model.  The  model  itself  and 
tne  cor rescomence  netween  tne  n.oael  and  tne  target  data  oase 
were  estarlisned  oy  setting  up  the  various  necessary  translation 
taoles  (see  (,ppendix  r( ) .  Tnese  tables  were  written  out  as  files 
to  be  read  t.ac<  during  query  translation, 

speea  versus  altitude  profiles  and  armament  configurations 
coulo  not  be  handled  entirely  tnrougn  tne  translation  tables,  it 
was  necessary  to  Insert  code  tor  them  in  an  AOT  special  linkage 
module,  which  is  called  to  handle  unusual  kinds  of  data  and  data 
linkages,  A  procedure  for  speed  versus  altitude  was  supplied  to 
determine  how  many  valid  values  there  were  and  to  Initialize  AQT 
array  element  seouencim  accordingly.  A  procedure  for  armament 
contlduratlons  was  suoplied  to  unravel  configurations  from  their 
tree  representation  ano  to  write- out  tne  lists  of  weapons  into  a 


temporary  space  for  sequential  searenino.  witn  these  procedures, 
tne  special  linkage  module  would  allow  access  to  the  first  and 
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subsequent  record  Instances  associated  with  speed  data  or 
armament  without  having  to  Know  now  this  was  accomplished. 

For  the  display  of  information,  it  was  also  necessary  to 
define  certain  virtual  fields  that  do  not  correspond  to  any 
target  data.  we  needed  some  way  to  identify  individual 
configurations,  marklno  wnere  one  weapons  list  ends  and  another 
begins,  and  some  way  to  show  the  altitude  values  implicitly 
associated  with  speeds.  This  was  done  oy  defining  virtual  fields 
for  data  records,  indicated  by  a  negative  offset?  instead  of 
being  extracted  from  a  target  data  record,  these  fields  would  be 
computed  by  a  call  to  a  special  module  containing  code  for  that 
purpose. 

in  the  AQT  demonstration  system,  the  special  llnKage  and 
virtual  field  modules  contain  all  the  code  dependent  on  the 
Soviet  aircraft  test  data  base.  The  remainder,  comprising  over 
ninety  percent  of  the  program  lines  for  query  translation  and 
including  all  the  major  AQT  algorithms,  is  independent.  The  idea 
of  a  portable  AUT  facility  readily  adaptable  to  different  data 
bases,  is  therefore  reasonaole;  and  in  fact  the.  demonstration 
system  snows  us  now  this  can  be  accomplished  with  a  table-driven 


scheme 
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6.i>  Performance 

Aithouon  tne  AOT  demonstration  system  was  not  designed  to  be 
a  full  query  facility,  it  does  allow  a  user  to  type  in  a  broad 
range  of  natural  lamuaqe  queries  and  to  get  correct  answers  bade 
from  an  actual  data  case.  The  system  is  quite  easy  to  use, 
especially  in  comparison  to  tne  data  access  facilities  usually 
found  on  medium-scale  processors.  (See  Appenolx  A  for  an  example 
of  an  actual  query  session.)  Tne  capabilities  of  tne 
demonstration  system  at  present  are  limited  by  two  factors:  the 
size  of  the  orammar  driving  tne  intermediate  translator  and 
uni.npiementeo  features  in  tne  target  data  base  translator.  The 
intermediate  translator  now  runs  witn  only  about  300  grammatical 
rules,  wMie  basic  logical  ana  arithmetic  operations  line 
negation,  quantification,  and  general  comparison  of  stored 
numerical  values  are  unavailable  in  the  demonstration  target  data 
case  translator. 

The  full  demonstration  system  in  its  full  FLEC5  FORTRAN 
version  currently  nas  a  total  tasK  image  size  of  about  120K  bytes 
IK  =  1024),  Tnls  is  overlaid  extensively  so  as  to  run  in  a 
maxlmuir  aodress  space  of  64K  bytes  on  the  DEC  PDP-11/70,  The 
system  now  fills  up  all  tne  available  address  space  while 
running,  but  we  should  be  able  to  reduce  this  regulrement  in  the 


I 
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prototype  query  facility  oy  taking  advantage  of  an  external 
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dictionary#  re.lijclnj  tne  amount  ot  Instramentation#  and  foregolnq 
some  of  tl'.e  at  ray  cnecKlna  ano  tracing  options  during  KtiHTKAiJ 
compilation. 

The  demonstration  nas  a  response  time  of  under  10  seconds 
for  queries  directed  at  tne  soviet  aircraft  data  oase.  Most  of 
this  is  in  waiting  for  data  nase  records  to  be  read  in  during  the 
search  and  retrieval  phase;  the  target  files  and  translation 
tables  were  all  stored  on  an  hkoS  cartridge,  wnlch  has  a  fairly 
slow  access  time.  Parsing  input  queries  taKes  relatively  little 
time,  almost  always  under  a  secono;  cnis  turns  out  to  be  much 
less  important  than  delays  introduced  from  tne  use  ot  a  remote 
terminal  with  a  slow  communications  rate.  The  time  required  to 
read  in  translation  taoles  from  dis<  files  is  also  relatively 
small,  mainly  oecause  tne  tables  themselves  are  small. 

The  main  cost  factors  In  running  tne  demonstration  system 
are  Its  size  and  Its  target  data  base  I/(j,  On  a  small  machine, 
the  system  can  take  up  a  significant  traction  of  main  memory  and 
consequently  load  down  operations,  altnougn  the  impact  of  this 
should  be  PC  more  than  that  of  runnim  a  lame  FUKTRAn  compiler. 
The  data  base  I/O  oroolem  will  oe  much  more  serious,  reguirino 
careful  optimization  of  programs  to  avoid  unnecessary  access  to 
secondary  storage.  This  is,  however,  as  mucn  a  proplem  of  the 
target  data  base  as  of  a  query  facility;  if  tne  data  oase  is  not 
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nesianeo  to  ra<e  tne  reqjirea  iclnos  of  access  etficlenti  tnen  tne 
oijery  facility  snoulo  not  oe  faalteil  'nucn.  Here  it  may 
Ironically  te  ur\(.iesiraole  to  maKe  access  to  a  data  base  easier 
tor  users. 

Tne  det onscratlon  system  as  written  in  KURTKAN  Is  about  as 
portable  as  can  be  expectea  in  usincj  mostly  standard  FORTRAN  I/O 
and  avoioinq  calls  to  an  operating  system  except  for  overlaying. 
Tne  nain  croolerr.  i/i  portability  will  oe  In  differences  between 
dialects  of  fORfRAfi.  ine  demonstration  system  employs  OPKn  and 
CLDSii.  statements  and  declarations  specifying  the  sizes  of  data 
Items  sucn  as  L'K;rCAp*l;  tnese  were  necessary  to  implement  tne 
Kinds  of  data  nanioulat Ion  reouireo  in  AOT,  but  will  not  exist  in 
many  FORTRAN  compilers.  Tne  situation  Is  Improved  consideraoly 
oy  the  FOURAf  T7  standards,  but  for  full  portability,  a  system 
would  broratly  nave  to  isolate  mucn  of  its  data  manipulation  in 
mtercnangeanle  modules.  ine  issue  of  how  mucn  portability  to 
aim  for  will  have  to  oe  adoressed  in  tne  subsequent  development 
of  a  full  query  facility. 
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7.1  The  User  Communication  System 

This  section  will  review  the  functional  design  of  the  FTO 
User  Coitmunlcatlon  System  (Usercom),  a  comoonent  of  the  FTd' 
update  program,  fne  purpose  of  tnis  review  is  to  identify 
features  of  the  Usercom  design  that  differ  in  approach  from  those 
of  AgT,  and  to  Indicate  possible  advantages  or  disadvantages  of 
those  features. 

Since  Usercom  exists  only  as  a  functional  design,  there  nave 
been  no  operational  tests  to  determine  the  effectiveness  of  the 
approach.  For  this  reason,  the  following  review  must  oe  taXen  as 
suggestive,  rather  than  definitive.  It  is  Intended  primarily  to 
highlight  those  differences  in  design  that  mlgnt  aid  in  maKlng 
AQT  more  responsive  to  the  needs  of  potential  users,  and  it  is 
not  Intended  as  a  critique  of  tne  usercom  design. 
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7.2  Kvaluation  Criteria 

At  the  reiuesc  o£  PAJC,  a  numoer  of  criteria  were  suggested 
for  the  evaluation  of  user  interface  languages  for  data  base 
hanagenent  systens.  In  somewhat  moalfied  form,  the  criteria 
sugqestert  were  these: 

7,2.1  tase  of  liearning 

A  nriirary  aovantaae  of  a  user  Interface  language  should  be 
the  ease  with  *nlcn  it  can  be  acquired  and  reme.noered  by  the 
novice  or  casual  user.  The  time  required  to  learn  the  operation 
of  a  seouence  of  function  tceys  should  be  comparable  to  the  time 
required  to  learn  a  natural  or  artificial  language  for  accessing 
tne  same  data  to  a  comparable  level  of  effectiveness. 

Note  that  some  period  of  traininvq  will  be  required  for  any 
interface  lanuoage,  even  tnougn  implementors  of  natural  language 
systems  sometimes  assume  tnat  users  require  no  training,  since 
the  lanouage  is  "natural"  to  them,  such  an  assumption  could 
aetuallv  ma^e  it  more  aitficult  tor  tne  user  to  employ  such  a 
system,  if  it  includes  undocumented  requirements,  restrictions, 
and  idiosyncracies  aosent  in  human  languages.  A  wellodesiqned 
selection  ct  user-oriented  function  Keys  could  then  be  easier  to 
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use  than  a  "natural"  lanouaoe. 


7.2.2  Power 

A  systeir  is  netter  to  the  degree  tnat  it  can  process  more  of 
the  queries  that  can  ordinarily  oe  expected  in  a  specific 
application.  Conversely,  if  tne  user  finds  it  inpossinle  to 
extract  information  clearly  contained  in,  or  implied  by,  a  data 
base,  then  the  query  language  will  be  less  useful  in  tnat 
application. 

The  last  words  should  be  emphasized,  since  additional  power 
is  undesirable  it  it  will  oe  unused.  For  example,  a  complex 
parser  will  be  superfluous  if  nearly  all  tne  queries  taxe  a  very 
small  number  of  syntactic  forms.  In  such  cases,  the  use  of  a 
relatively  small  number  of  function  Keys  may  be  considerably 
easier  than  tne  use  of  a  sophisticated  system  tor  analyzing 
natural  language.  A  large  vocabulary  is  not  useful  if  most  of 
the  words  are  never  actually  encountered.  Unneeoed  power  will 
simply  be  a  waste  of  resources. 


7.2.3  Ease  of  Ose 


An  "ideal"  natural  language  interface  should  accept  a 
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problem  statement  in  any  words  that  the  user  requires,  A 
formalizeo  artlticlai  language  nay  require  extensive  reworKing  of 
the  problen  statement  in  order  to  fit  the  specified  formats. 
Although  this  criterion  is  somewnat  more  "subjective"  tnan  the 
first  two,  it  is  l-nportant;  users  will  oecome  discouraged  with  a 
system  that  lemands  extensive  work  in  getting  the  problem 
formulated  correctly. 

7.2.4  Correctness 

This  evaluation  criterion  is  intended  to  locate  instances  in 
whicn  the  user  enters  a  ouery  with  a  straightforward  English 
language  neaning,  out  whicn  is  given  some  otner  meaning  by  tne 
system.  To  take  a  ratner  artificial  example,  suppose  tnat  the 
user  asks:  "how  many  «!lG-i7s  do  the  Vietnamese  have?  what  Is 
their  range?"  If  the  system  were  to  interpret  "their"  as 
referring  to  tne  Vietnamese  rather  than  to  the  MIG-I7s,  it  could 
produce  output  tnat  was  wildly  incorrect.  Such  errors  may  be 
more  serious  in  a  natural  language  system  tnan  in  an  artificial 
lanquaae  system,  since  me  chance  for  misinterpretation  of 
natural  larguaje  may  be  greater. 

tn  an  important  article,  Cnristlne  Montgomery  has  pointed  to 


one  of  tr.e  major  weaknesses  of  tne  natural-language  approach 
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91364}.  TMs  point  ot  view  clearly  provides  some  ot  tne 
Incentive  to  develop  lisercom  as  a  system  organizei  around 
deslqnated  function  Keys,  rather  than  around  natural-lanauaqe 
Input. 
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7.i.5  naturalness 

The  language  should  permit  tne  user  to  employ  a  natural  form 
of  tne  language.  The  PEI.  system,  tor  example,  sometimes  requires 
rather ■ stilted  Engllsn:  "Who  are  the  snippers  of  shipments  whose 
cargo  type  is  general  mercnanolse?"  CTnompson,  Hozena  Henisz,  and 
Thompson,  FredericK  «.,  "Rapidly  Extendaole  Natural  Language," 


Proceedings,  ACM  National  Meetims,  1979,  pp 


173-192.)  Thus  a 
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natural  lanouaie  system  coulo  oe  less  "natural"  for  tne  user  than 
a  set  ot  clear lv-«lefineij  function  Keys,  if  tne  latter  bore  some 
cor resporrience  to  tne  user's  o*'n  definition  ot  the  oroolem. 


7.2.f>  rielpfulness  of  error  iressaqes 

«nen  the  system  tails  to  interpret  a  query*  tne  response 
shoulo  be  one  tnat  assists  tne  user  in  reformulating  it  (cf. 
Good,  f.F.,  "Seven  Steps  to  Rendezvous  rfitn  tne  Casual  User,"  IBM 
Research  Report  R.I  li33,  Jan.  17,  1974).  An  uninformative 
message,  such  as  "En?"  is  netter  than  no  message  at  all;  but  the 
system  should  oe  designed  so  tnat  failure  to  produce  an 
acceotable  Interpretation  should  retain  sufficient  Information  to 
permit  a  reasonable  response  to  tne  user.  Because  it  is 
sometimes  olfficult  for  a  system  to  locate  the  precise  source  of 
error  vhen  an  interpretation  falls,  it  will  be  Important  to 
evaluate  the  correctness  of  error  messages  In  an  implemented 
system.  In  tne  evaluation  of  a  functional  design,  of  course, 
correctness  would  oe  difficult  or  Imoossible  to  determine; 
nevertheless,  a  review  of  proposed  error  responses  will  indicate 
tne  likelihood  that  they  will  be  of  value  to  the  user. 
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7.2.7  syster  .rapacity 

Since  rany  systeris  n.'^ve  oeen  developea  on 

an  experlffental  nasls,  very  oati  oases,  it  is 

i.TDortant  ro  oeter'^ine  ■•/netner  cnev  can  ce  anplieo  to  oata  oases 
ot  sloniticanc  size.  i  .ote,  tor  exaT.Ue,  tnat  ^inoijrao's 
Well-Known  5Hf<  )i,ij  ooerateo  *  1 1  >  a  vocaoiiiary  ot  only  2  JO  woros 
(Ct.  wlnogra  i,  ferrv,  ‘jnoerstanoin  i  \atural  oanoiiage,  '.e  v  Yoric: 
ACdfieoic  Press,  lo/ij.) 

In  trie  evaluation  ct  a  taoctional  nesion,  mere  shoulo 
tneretore  ne  so"-e  inlication  t:iat  tne  lesion  can  ne  anoiled  to  a 
data  nase  ct  s i  m i f  leant  size  --  enou  jn  to  ^larrant  tne  cost  of 
i’TioleiT'entat  1  on. 


7.2.ri  VlslMlity  ot  operation 

joes  tte  svsteTi  cerrt'it  trie  user  to  insr'ect  tne  joery  at 
Intermediate  points  "-  say,  oet*’een  tne  ti'ne  tne  iviery  nas  oeen 
translated  into  an  internal  lanruane  ano  trie  time  mat  actual 
searchino  necins?  For  tne  more  experieiiceo  user,  it  will  ce 
Important  to  re  anle  to  locate  errors  In  retrievals  oetore  tney 
occur;  In  particular,  to  locate  errors  oetore  tney  soax  up  nours 
of  wasted  racnine  time. 
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At  the  sd  le  tiTp,  tor  tne  c.isudl  user  witn  a  relatively, 
simple  cuerv,  tre  ooooslte  virtue  Is  needei:  transparency  of 
operaticr.  ror  tne  casuil  user,  tne  inner  '*or<inq  of  the  system 
is  Of  little  interest.  It  is  only  *nen  sometnina  nas  gone  badly 
\»rona  tr.dt  suci  a  user  nil!  »ant  to  sten  cnrouan  tne  Details  of 
tne  retrieval ,  un.ier  tne  lui.iance  of  an  experienced  user  or 
svsteTi  "dnccipr,  to  locate  tne  precise  point  where  an  instruction 
was  misinterrretei. 


I, 2,':!  Se if-doc  i.-'entdt i on 

It  srcnln  oe  lossiole  to  revie*  nardcopy  outout  from  a 
retrieval  session,  after  several  months ,  and  to  oe  able  to 
inrerorct  tne  ,nal  ot  each  o'lery.  It  would  ne  unfortunate  to 
receive  sevtril  peantitully  forn.utted,  carefully  clotted  charts 
or  urarts  without  any  intortation  concernintj  tneir  ouroort.  A 
major  ocvantdie  ot  a  natural  lanuuaoe  system  should  oe  the  ease 
Of  readirc  olrectly,  from  tne  queries  and  tne  responses,  exactly 
wnat  the  user  *as  tryinu  to  find  out.  Similarly,  a  system  lixe 
i'sercor  shouio  orovi de  output  t^at  is  easily  Interpreted  oy  tne 


user 
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7.2.10  Abbreviations  and  Shortcuts 

For  many  users,  typing  may  be  a  dittleult  and  lengthy 
process.  Is  It  possible  to  aborevlate  tne  auery  In  sucn  a  way  as 
to  permit  much  shorter  InoutV  For  example,  can  minor  function 
words  ("a",  "tne",  "Is",  etc.)  oe  omitted  from  tne  nuery?  Can 
the  user  or  tne  system  manager  introduce  aooreviatlons  for 
frequently  used  terms  and  onrases?  will  tne  system  provide 
pre-defined  function  <eys,  tor  example? 

7.2.11  Notational  idlosyncracies 

Does  the  lanouage  require  a  large  number  of  notational 
devices  and  soecial  formats  or  symools,  which  might  detract  from 
concentration  on  tne  problem?  (Cf.  Sammet,  Jean  E.,  Programming 
Languages!  dlstory  and  Fundamentals,  Enolewood  Cliffs; 
Prentice-Hall,  19b9). 

7.2.12  pesource  Requirements 

For  a  given  data  base,  what  are  tne  requirements  in  terms  of 
primary  and  secondary  storage,  central  orocessor  time,  terminal 
time,  and  peripheral  time?  Can  the  system  pe  Implemented  on 
small  or  nedlum-sized  equipment,  or  ooes  It  require  a  very  large 
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computer  maintrame?  does  It  require  a  dedicatea  processor,  or 
can  it  ce  time-snared  -itn  otner  processes? 


7.2.13  portability 

Is  tne  system  available  in  a  standard  languaqe  available  on 
a  variety  ot  maciiines  litcelv  to  be  found  in  the  Intended 
installations?  Is  the  coding  niqhiy  machine-dependent,  or  does 
it  PiaVe  use  only  of  *iaely  available  features?  Is 
speciai-puri ose  hardware  reguirea?  Does  it  normally  operate  with 
widely-used  terminal  eouipment? 

The  followinq  Items  are  reaarded  as  somewhat  beyond  the 
state  of  the  art  for  operational  systems  using  large  data  bases. 
They  are,  however,  In  use  for  smaller,  experimental  systems  and 
should  be  consioered  typical  of  many  desirable  options. 


7.2.14  Spelling  corrector 

* 

An  effective  editor  Is  oetlnitely  not  beyond  the  state  of 
the  art,  and  should  oe  regarded  as  a  oosltlve  element  In  any 
implementation,  (n  audition,  techniques  for  modltylng  minor 
misspellings  (ana  Informing  tne  user  of  changes  proposed)  nave 
peen  used  in  correcting  student  programs,  and  may  be  applicable 
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to  data  base  management  systems,  wnen  a  spelling  corrector  fails 
to  locate  a  word  in  its  vocabulary  it  would  not  only  print  an 
error  message,  but  would  also  suggest  some  possible  alternative 
spellings.  If  they  were  acceptable  to  the  user,  they  would  oe 
substituted  automatically. 


7.2.15  Cooperation  with  User 

"Cooperative"  is  used  to  describe  a  system  that  attempts  to 
anticipate  the  user's  information  needs.  (Cf,  Kaplan,  S. 
Jerrold,  "On  the  lUfference  Between  Natural  Language  and  High 
Level  Ouery  Languages,"  Proceedings,  ACP  National  Meetings,  1979, 
pp.  27-38),  Consider  the  following  answers  to  the  question:  o. 
Which  Cambodian  oases  that  can  service  neavy  Dompers  can  also 
service  tactical  fighters?  Al.  None  A2.  No  Campodlan  bases  can 
service  heavy  bombers. 

The  second  reply  obviously  provides  tne  user  with  an 
Important  piece  of  Information  that  is  ignored  in  the  first 
reply.  (Cf.  aelnap,  vuel  u.,  Jr.  and  Steelf  Thpmas  B.,  Jr., 
The  Logic  of  Questions  and  Answers,  New  Haven:  /ale,  1976?  and 
Lehnert,  Wenoy,  The  Process  of  Question  Answering:  A  Computer 
Simulation  of  Cognition,  New  KorK;  Halsted,  1978).  Determining 


the  presuppositions  of  the  user's  query  would  oe  an  important 
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teature  ot  a  system  maKino  a  significant  contribution  to  tne  ease 
of  maicing  queries. 

7.2.16  Approximations  and  Near-Misses 

(Cf.  SiKlossy,  Laurent,  "Impertinent  Question-Answering 
Systems:  Justification  ana  I'heory,"  Proceedings,  ACM  National 

Meetings,  1978,  pp.  39-44).  Consider  the  following  pair  of 
responses: 

Q.  rthat  Cninese  troops  are  now  active  in  Cambodia? 

Al.  None. 

A2.  None,  out  tne  Third  Division  is  stationed  five  miles 
from  the  border. 

The  second  renlv  helps  to  give  the  user  information  that 
might  well  be  relevant,  out  wnich  did  not  appear  in  the  query  as 
it  was  first  formulated. 

The  last  tnree  features  mayoe  taken  as  examples  of  work  that 
is  actively  being  pursued  in  research  in  artificial  intelligence, 
out  Which  is  not  yet  ready  for  Incorporation  in  large  data  base 
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manaqetr.ent  systems.  fnev  seem  to  require  resources  that  far 
overbalance  tnelr  apparent  oenefits;  and  there  is  some 
lllcelihood  that  they  will  provide  intoleraole  levels  of 
noise--l.e.,  unwanted  information.  these  and  other  experimental 
features  should  nevertheless  ne  taken  into  consideration  in 
evaluatlna  comoetlnq  aata  oase  access  lanquages. 


7.3  Review  of  dsercom 

The  sixteen  criteria  that  nave  oeen  suqaested  here  may  be 
used  as  the  oasis  for  a  review  of  the  functional  design  of 
Usercom,  with  empnasis  on  useful  features  for  incorporation  into 
the  Advanced  juery  facility.  Tne  paraarapns  in  the  following 
review  have  been  numbered  to  correspond  to  the  evaluation 
criteria. 


7.3.1 


Usercom  may  be  somewhat  easier  to  learn  tnan  mlont  appear  at 
first,  to  the  extent  that  it  follows  the  normal  sequence  of 
activities  now  used  by  analysts  in  proiucina  FfD's  reports.  For 
new  analysts>  tne  trainlno  procedures  could  well  be  built  upon 
tne  use  of  aut-omated  aids  in  retrievino,  manlouiatinq,  and 


formatting  required  information 


such  a  training  program  would 
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not  ne  intrinsically  irore  ditticult  tnan  a  proqram  that  relied 
wholly  on  maniial  procedures. 

In  the  absence  o<  user  experience  with  Usercom,  it  is 
particularly  difficult  to  determine  the  ease  of  learning.  It 
nevertheless  seems  to  present  several  proolems  from  the  point  of 
view  of  human  factors: 

o  Usercom  requires  the  analyst  to  use  a  sequence  of 
special  purpose  function  <eys,  alternating  these 
with  names  that  are  entered  through  a  typewriter- 
Uxe  Keyooard.  The  sequence  of  entries  is  rigid, 
resemolinq  tne  required  sequences  of  a  programming 
language.  Because  of  this  rigidity,  users 
adverse  to  learoinq  a  orograraminq  language  may  also 
find  It  unpleasant  to  comply  with  the  sequence  of 
actions  required  by  Usercom.  They  may  not  li)ce  a 
rlaia,  somewhat  arbitrary  form  of  input, 
o  Although  Usercom  reduces  the  amount  of  typinq  re¬ 
quired  of  the  user,  it  does  not  eliminate  the  need 
for  typing.  Jn  the  contrary,  the  user  must  first 
press  one  or  more  function  <eys,  then  must  transfer 
to  the  typewriter  Keyboard,  then  move  bacK  again  to 
the  function  Keys,  and  so  on  throughout  tne  input 
session.  For  an  exoerienced  typist,  this  is  liKely 
to  be  ratner  frustrating,  because  he  cannot  Keep  nis 
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hands  In  tne  normal  position  required  for  toucn 
typing,  and  must  relocate  his  hands  before  each 
typewriter  input.  For  such  a  typist,  locating  and 
using  a  function  Key  may  be  more  dltflcult  than 
typing  a  brief  function  name  at  tne  Keypoard. 
o  The  use  of  prompting  messages  on  tne  screen  will  be  helpful 
to  the  oeglnning  user  in  preoarinq  tne  input  in  the 
correct  sequence.  It  may  oe  difficult,  however,  for 
the  user  to  looK  at  the  screen,  then  looK  downward  and 
refocus  on  the  Keypoard  to  locate  the  correct  function 
Key,  then  looK  up  at  tne  screen  again,  and  so  on. 
Differences  in  lighting  between  tne  screen  and  tne 
Keyboard  may  cause  some  eyestrain  over  a  long  period  of 
use.  An  experienced  typist  would  prefer  to  leave  nis 
hands  in  the  normal  position,  without  looKing  at  them, 
rather  than  have  to  fhlst  his  vision  from  screen  to 
Keyboard  oetween  each  use. 

lilKe  other  nuraan  factors  considerations,  these  comments 
would  have  to  be  tested  in  an  actual  implementation  of  Usercom  to 
determine  their  applicability.  From  the  point  of  view  of  AQT, 
however,  it  does  not  appear  that  there  are  features  of  Usercom 
that  could  be  adapted  to  Improve  ease  of  learning.  At  worst  -- 
pending  tests  with  actual  users  --  the  A>JT  natural-language 
approach  does  not  appear  to  be  significantly  more  difficult  to 
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learn. 


7.3.? 


The  potoer  of  the  iJsercon>  system  may  oe  limited  by  the  number 
of  function  Keys  available  In  the  particular  hardware 
configuration  cnosen.  However,  tne  most  serious  apparent  problem 
is  in  tne  update  of  tne  system  as  new  functions  are  required  and 
old  functions  are  replaced  or  eliminated.  Since  new  function 
Keys  must  be  designated,  new  templates  will  oe  required. 
Usercom,  however,  plays  a  strictly  limited  role;  it  is  not  a 
general  purpose  user  interface,  but  an  interface  tailored 
specifically  for  access  to  sris  by  FID  analysts.  It  requires 
precisely  as  much  cower  as  is  needed  to  extract  and  combine  data 
from  the  STJS  data  base  and  to  orepare  reports  that  needed  by 
FTD.  More  power  tnan  this  would  oe  wasted.  In  addition,  after 
some  user  experience  with  the  system,  it  could  be  expanded  to 
include  functions  tnat  were  needed  but  not  included  in  the 
initial  breadboard  system. 

The  Usercom  goal  Is  tnerefore  rather  different  from  tnat  of 
AOT,  In  that  AOr  is  intended  to  provide  an  easily  portable  system 
for  use  by  persons  wltn  a  variety  of  oacKgrounds  and  needs  in 
accessing  data  bases  of  differing  designs.  Usercom  would  be 
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optlmizao  tor  access  to  the  STts  data  base,  tor  a  user  group 
limited  to  1 ra  analysts.  Since  goals  of  tne  two  projects  are 
quite  oifterent,  comoar Isons  in  terms  ot  oower  would  be 
inapproi'flate. 


7.3.3 


The  ease  o£  use  of  tne  Usercom  aporoach  snould  oe  a  primary 
dovantaue.  without  operational  testing,  of  course.  It  would  be 
premature  to  attempt  to  determine  user  acceptability, 
^ievertheless ,  there  is  a  strong  argument  to  oe  made  In  favor  of 
the  use  of  function  Keys,  rather  than  the  requirement  that  users 
type  function  names  on  a  typewriter  style  Keyooard.  This 
approach  shoud  aopeal  particularly  to  those  users  who  find  typing 
difficult. 

Arqunents  for  the  usercom  aporoach  suggest  a  need  for 
facilities  within  Agt  that  will  nelp  to  improve  it  ease  of  use. 
Priciarily,  sucn  facilities  are  Intended  to  reduce  the  amount  of 
typing  and  thereby  to  make  it  easier  for  the  non-typist  to  use. 
Specif Ically,  AOT  ml<jht  consider: 

o  Use  of  anbrevlations.  It  should  be  possible  to  use 
just  one  or  two  letters  of  a  command  word,  rather 
than  the  whole  word.  For  example,  "f  might 
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abbreviated  "find",  and  "nm"  mldht  aboreviate  "how 
many*. 

o  Tolerant  syntax.  Ayr  shoulo  do  no  more  oarslnq  than 
is  necessary  to  set  up  the  required  searcn  routines. 
Omission  ot  a  function  word  (“tne,"  "and,"  "is)  should 
not  cause  program  failure.  Tne  user  should  thus  oe 
able  to  employ  a  very  concise  format  for  queries, 
o  Since  misspellinqs  may  occur.  It  will  be  Important  to 
be  able  to  deal  with  them  without  causing  the  user  in¬ 
convenience.  For  this  purpose,  a  good  text  editor 
will  oe  of  assistance.  tn  a  more  amoitlous  approach, 
a  spelllm  corrector  might  oe  employed,  to  checK  inputs 
against  a  list  of  common  mlsspelllnis,  or  to  locate 
other  words  with  spellings  that  are  similar  to  the 
input.  Because  ot  tne  liKelinood  of  error  in  a  spell¬ 
ing  Corrector  that  deals  with  unrestricted  natural 
language.  It  will  be  essential  to  secure  the  user's 
agreement  before  making  changes.  For  example: 

Is  cnine  still  using  'diG-l7  flgnters? 

"Chine"  not  found.  Do  you  mean  "China"? 
ye« 

At  this  point,  an  editing  routine  would  substitute  the 
suggested  spelling  into  the  query  and  proceed. 

Use  of  aids  sucn  as  these  could  malce  the  AOr  natural- 
language  approach  as  easy  to  use  as  tne  Usercom  aporoach. 
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7.3.4 


by  "correctness"  Is  r.ieant  tne  anility  ot  the  system  to 
interpret  a  user's  Intentions  in  -lays  tnat  are  satisfactory  to 
the  user,  wavs  tnat  carry  out  tne  user's  Intentions.  The 
criterion  reflects  our  aissatlsfactlon  with  operation  of  one 
major  natural-lamuage  system  in  which  the  system  sometimes 
tailed  to  understand  queries  anj  proouced  Incorrect  parsings.  In 
such  cases  an  incorrect  answer  would  be  returned  to  the  user 
without  warnini. 


me  Usercom  approach  reoresents  one  way  of  avoiding  this 
Klrid  ot  error,  me  user  is  ulven  tne  responslolllty  ot  preparing 
a  ouery  in  a  rigid,  unambiguous  form,  wnich  the  system  can 
Interpret  and  execute  in  only  one  way.  When  errors  occur,  they 
are  more  likely  to  oe  user  errors,  caused  by  a  failure  on  the 
part  ot  the  user  to  employ  the  proper  operators  in  the  correct 
seduence . 


Krrors  In  a  natural-language  system  are  likely  to  be  of 
anotner  oroer.  In  such  a  system,  the  user  uses  whatever  phrases 
and  torns  he  would  normally  use  in  formulating  a  query.  The 
system  then  has  the  responsibility  for  translating  these  Into  a 
formula  nearingfui  to  tne  system.  This  translation  process  is 


difficult 


and 


Is 


subject  to  tne  errors  that  normally  occur  in 
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natural  langua^je  --  tne  result  ot  amoiguities  in  xords 
(equivocation)  and  sentence  structure  (amphlooly) .  decause  of 
the  conplexity  ot  natural  language ,  there  will  always  be 
sentences  ireanlmful  to  tne  user  that  are  incorrectly  interpreted 
by  tne  program.  Tne  proole.m  of  pronoun  reference,  for  example, 
is  particularly  ditticult. 

In  comparing  tne  ACT  approach  *itn  that  ot  Usercom,  then,  we 
are  comparing  alternatives  with  very  different  sources  ot 
potential  errors.  in  Usercom,  errors  are  most  lifcely  to  occur  as 
the  user  attempts  to  translate  an  Information  reouirement  into 
the  lanquade  of  the  system;  in  AOl,  errors  n^ay  occur  wnen  tne 
system  Interprets  an  input  incorrectly.  Performance  in  usercom 
Is  llKely  to  improve  as  tne  user  learns  more  aoout  system 
requirements  ano  is  tetter  anle  to  tailor  lueries  to  fit  tne 
system.  In  avi'C,  rerforuiance  improves  witn  rime  as  PlausiPle 
errors  are  identified  and  the  system  is  improved,  experience 
with  noth  systems,  Usercom  and  ADT,  is  required  to  determine  the 
deqree  to  whlcn  errors  can  he  reduced  or  eliminated  under  either 
approach. 


7.3.5 


The  Uscrcom  aonroach  to  system  design  defines  "naturalness 
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in  terns  ot  tne  ri.jtaral  seaaence  of  activities  tnat  tne  analyst 
ccrtorns,  jt  is  iritenrted  to  provide  options  in  an  ordering  and  a 
torniat  that  correspond  to  the  *av  in  of  analysis  nas  dictated  the 
aesidh  ot  the  systen. 

"naturalness"  in  Ayt  has  a  soitevnat  ditterent  meaning. 
Sere,  it  refers  to  ho*  a  numan  user  normally  phrases  a  query, 
fne  use  ct  relational  hierarchies  to  model  a  data  oase  was  was  an 
attempt  to  provloe  a  close  approximation  to  tne  way  humans 
normally  ttri^ulate  tneir  queries,  aecause  ot  these  differences 
in  aoproacr,  tne  degree  to  wnicn  tne  naturalness  of  one  system 
can  ce  transferred  to  the  other  is  not  great. 

7 .  i .  h 


The  iielptulness  ot  error  messages  would  oe  an  important 
criterion  for  review  ot  a  runnino  system.  At  this  time,  Usercom 
exists  only  in  tne  form  of  a  <iensrali2ed  system  description. 
While  AOl  has  oeen  Implemented  in  a  demonstration  system.  In 
neither  case  is  tnere  sutticlent  experience  to  oe  able  to 
oetermine  the  nelpfulness  ot  error  messages. 
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Again,  there  are  no  firm  data  upon  »ihlcn  to  case  estimates 
of  system  capacity,  botn  Usercom  ana  AtfT  nave  been  aesianed  for 
eventual  application  in  tne  production  environment,  where  data 
bases  are  potentially  very  large.  It  will  ne  assuneo  tnat  botn 
systems  will  be  capable  of  deailno  with  very  large  data  oases  in 
tneir  operational  versions. 

7.3.B 

VisibiXlty  of  operation  snould  oe  interpreted  as  meaning  tne 
ease  with  which  proolems  are  locatea  --  particularly  problems  in 
the  interpretation  and  execution  of  queries.  This  problem  does 
not  appear  to  arise  in  tne  usercom  approach,  since  tne  primary 
locus  for  errors  would  ^e  the  user's  interpretation  of  a  query  in 
the  language  of  tne  system.  In  AUr,  tne  approach  has  peen  to 
maximize  the  transparency  ot  tne  system  to  tne  user,  wno  need  not 
be  aware  ot  tne  structure  of  the  data  base,  or  of  tne  specific 
procedures  that  are  used  to  extract  information  from  it. 

Both  Usercom  and  aut,  then,  rely  on  transparency  ratner  than 
visibility  as  a  desideratum.  Partner  experience  with  both 
systems  Should  show  whether  there  is  actually  a  need  tor  greater 
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visibility,  l.e.  tne  aegree  to  wnicn  tne  user  can  see  exactly 
what  the  system  is  -lolna. 


7.3.9 


usercoir  ooes  not  appear  to  be  selt-aocumenting  in  the  sense 
of  tnls  criterion.  It  would  be  rather  hard  tor  an  Inexperienced 
user  to  determine  tne  Intent  of  a  six-montn-old  record  of 
Interactions  with  the  system  --  if,  indeed,  the  user  dialogue 
woulo  oe  retained  at  all  oy  the  system, 

AVT  is  oesioned  in  such  a  way  as  to  be  self-documenting, 
since  the  full  dialogue  will  provide  even  the  casual  reader  with 
a  clear  picture  of  the  original  query  and  of  the  system's 
response.  This  documentation  will  be  of  value  when  it  is 
necessary  to  determine  tne  meaning  of  lengthy  tables,  charts,  or 
other  output  tnat  coulo  not  easily  oe  regenerated. 

7.3.10 

Abbreviations  and  shortcuts  were  suggested  in  item  ?.?.? 
above  as  ir.ethods  of  reouclng  tne  need  tor  lengthy  typing. 
tJsereom  represents  an  approach  where  all  ma-Jor  system  functions 
are  supplied  through  function  Keys,  representing  an  extreme  form 
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of  apbreviatlon.  AQT  has  a  very  tolerant  syntax,  pernltting  tne 
use  of  abnteviaten,  telegraphic  inputs  as  long  as  they  suffice  to 
disambiguate  the  ouery;  no  rlgio  adherence  to  Kngiisn  grammar  Is 
required.  (inis  aporoacn  provides  a  resoorise  to  tne  position 
taxen  In  Christine  Montgomery's  paper,  "is  natural  Language  an 
Unnatural  t»uery  uan  jua  je  ?" ) 

7.3.11 

AQT  is  oeslgnei  to  be  free  of  notatlonal  idiosyncrasies  that 
might  detract  from  concentration  on  the  orooiem.  The 
natural-language  approach  Is  intendeu  to  free  tne  user  from  tne 
need  to  employ  a  specialized  syntax  or  set  o»  sympols. 

Usercom  uses  a  rather  different  appro  *c,,  :h.- 
speclallzeo  syntax  consists  of  a  seout’  re  of  xeys  to  oerform 
elementary  functions  of  tne  system,  a  pro'  r  immintj  option  permits 
the  user  to  define  functions  or  macros  that  combine  tnese 
primitive  operations. 

inis  criterion  was  suggested  as  a  resr  nse  to  comments  oy 
Jean  £.  Sammet,  in  ner  Programming  L-nguaues;  History  arid 
Funaamentals ,  wnere  sne  points  to  the  use  Oi  curious  or  difficult 
conventions  within  tne  languages  under  review.  Meitner  tne 
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usercon  ror  cne  aoT  approacn  seems  to  be  supject  to  tbe 
criticisrs  tbat  she  raises.  'levertneless ,  i aiosyncrasies  might 
well  appear  In  oneratlonai  i  t.piementatlons  >£  either  system;  the 
lacK  of  experience  with  tne  svstenis  agai  md<es  application  of 
trie  criterion  iltticalt. 


7 . 3.  W 


In  terms 

g£ 

resource 

requirements , 

.■>tn  approaches  seem 
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since  tne 
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V  ^  1  i  r  ;  !  f- 

ror  ooth  of 

them  woulo  re 

tne 

store  je 

of  formatted 

J  t  »  d  . 

search 

mecnanistrs  reTiirea  to  access  the  data,  rne  front  end  for  ooth 
systems,  oiven  tne  n.odest  reguirtr.ents  of  the  usercom  approach, 
would  stiovi  the  largest  difference.  AJT  ta<es  the  responsibility 
for  translatim  tne  user's  guerv  into  a  set  of  commands  for 
search,  retrieval,  transformation,  and  output.  Usercom  places 
responsinll 1  tv  upon  tne  user  tor  the  first  of  these  functions, 
tne  translation  of  an  information  requirement  into  the  restricted 
syntax  of  the  system.  The  greater  power  of  the  AGT  approach  win 
reguire  procortionatelv  greater  system  resources. 


7.3.13 


rne  nortaollity  of  the  Ayr  system  will  oe  one  of  its  primary 


Page  7-26 


Comparison  with  an  St.X  Data  Base  Communication  Facility 

advantages.  It  Is  designed  tor  rapid  imp le.nentatlon  in  a  variety 
of  hardware  environments,  for  accessing  a  wine  range  ot  formatted 
data  bases.  Usercom  is  intended  for  a  single  tyoe  of  data  base. 

Another  cnaracteristlc  of  the  usercom  aporoacn  that  will 
limit  its  portahillty  is  the  use  of  LISP  as  tne  system  language, 
where  AQT  has  used  foktpau.  Although  ootn  languaoes  are  aoout 
the  same  age  --  datina  from  the  late  1950's  --  tne  number  of  LtSP 
implementations  is  constderaoly  smaller  than  tne  number  of 
roPTRAN  in plementatlons .  In  addition,  there  are  fewer 
programmers  trained  in  LISP  tnan  in  FJprPA’J.  As  a  result, 
Uscrcom  is  ll<ely  to  oe  mucn  less  portaole  to  new  machines  than 
is  AyT.  (Kone  of  these  comments  are  intended  to  suggest  tnat 
FORTRAN  is  suoerior  to  LISP  as  a  language  for  i  nr.  le  nentatlon  of 
systems  like  Usercom;  on  the  contrary,  LISP  is  a  weli-desioneu, 
flexible  language  particularly  appropriate  for  sucn  applications. 
PASCAL  would  be  another  .  language  superior  to  KdkTPAi'i  to  oe 
considered) . 

The  remaining  evaluation  criteria  were  suggested  as  typical 
of  extensions  of  tne  natural  language  aooroacn  tor  the 
development  of  user  Interfaces.  'Mone  of  them  should  be  regarded 
as  within  the  state  of  the  art  tor  large  data  base  .management 
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7.4  Summary 

Several  elements  of  the  Usercom  approach  have  been  reviewed 
and  emchaslzed  nere: 

o  The  close  attention  to  the  actual  operations  of  FTD 
analysts,  to  their  information  needs,  and  to  the  need 
for  nrooiicina  formatted  output  nave  been  emphasized 
iri  usercom  and  are  important  considerations  in  the 
development  of  A<^T. 

o  Comments  concerning  the  difficulties  that  some  users 
hill  find  in  usin'?  a  typewriter  Keyboard  should  be 
reviewed  to  insure  that  AOT  is  easy  to  use. 

0  The  need  for  an  effective  implementation  language, 
such  as  LISP,  Should  oe  considered.  A  specialized 
language  llt<e  PASCAL  might  also  be  reviewed. 

0  Comments  concerning  tne  Problems  tnat  users  find  in 
producing  syntactically-correct  inouts,  correct 
spellings,  and  other  non-technlcal  details,  should  be 
reviewed  carefuiiy.  In  particular,  it  should  be 
possible  to  matce  corrections  in  an  input  without 
retyping  tne  entire  line. 

o  More  generally,  a  close  attention  to  human  factors 
will  oe  a  major  consloeratlon  for  AQT  development. 
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SECT  KIM  H 
Conclusions 


8.1  Status  an'i  results 

Our  experience  in  building  a  de.iionstratl on  system  tor  AOT 
Indicates  that  a  portable  natural  language  data  base  query 
facility  is  not  only  feasible,  out  also  Jirell  oitnin  tne  domain  of 
present  established  data  base  and  natural  lan<7uade  orocessing 
techniques.  Tne  most  significant  aspect  of  the  demonstration 
system  is  its  overall  simplicity  in  contrast  to  its  capabilities. 
The  simplicity  is  refleeted  in  tne  tact  that  such  a  system  could 
be  implemented  in  euBT»<AN  on  a  DSC  P0P-it/4b  and  that  we  nave 
been  aole  to  describe  all  tne  important  aspects  ot  tne  system 
here  In  this  report.  An  eventual  prototype  query  tacillty  of 
course  would  have  to  ao  considerably  oeyond  the  demonstration 
system,  but  its  basic  £rame*’or<  should  still  be  the  same. 

Most  of  the  code  written  tor  tne  demonstration  can  oe 
readily  adapted  to  a  FURTHA'J  implementation  of  a  prototype  query 
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tacllity.  As  noted  already,  the  choice  of  FORTRAN  here  is  solely 
on  the  basis  ot  Its  near-universality  although  its  portability 
may  well  te  questioned;  in  practice,  we  founa  it  troublesome  to 
wort  with  even  with  a  FLFCS  preprocessor  to  aid  in  maintaining  a 
top-down  structurea  proaraiomlng  discloline.  It  a  specific 
application  called  tor  implementation  in  a  modern  programming 
lanouaoe  like  pascai,,  it  would  he  fairly  straightforward  to 
translate  from  existing  F0R1ka!'1  code  into  it;  and  in  fact  the 
resulting  cooe  snould  oe  much  improved  since  the  demonstration 
system  has  had  to  employ  convoluted  means  in  FORTRAN  to  come  up 
•1th  the  equivalent  of  pointers  for  strings,  structured  data 
types,  recursion,  and  local  variables. 

If  neeo  oe,  the  present  demonstration  system  itself  could  be 
applied  to  provide  natural  language  access  to  an  existing  target 
data  base,  'me  system  was  designed  to  avoid  the  appearance  of 
belno  tleo  to  a  specific  test  data  case;  we  can  redirect  it  to 
other  taroei  data  oases  oy  simply  changing  its  external 
translation  tanles,  assuming  that  the  structure  of  the  target 
oata  base  is  fairly  ortnodox.  fhe  demonstration  system  would  of 
course  corstltute  only  a  part  of  a  prototype  query  facility,  but 
It  woulo  nevertneless  allow  tor  experimental  use  of  natural 
language  access  to  actual  data  b'ases. 


Experimental  use  ot  AOT  will  be  essential  to  further 
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development.  ^le  need  to  get  more  exoerlence  Jitn  tne  Kinds  of 
data  bases  «here  natural  language  access  vould  be  appropriate  and 
wltn  the  kinds  of  patterns  of  access  tnat  mignt  be  expected,  we 
also  need  to  identify  specific  information  problems  of  Doth  users 
and  their  organizations  where  new  technologies  might  be  directed. 
Because  the  success  of  an  information  system  must  in  the  end  oe 
judged  by  how  well  It  is  accepted  oy  its  users>  it  is  crucial 
tnat  they  be  able  to  have  some  say  in  how  tnat  system  should  turn 
out. 

8.2  Rvaluatlon  criteria 

The  ACT  approach  is  not  concerned  with  developing  the 
ultimate  natural  language  system.  Such  a  goal  is  of  theoretical 
interest,  but  it  is  only  tangential  to  tne  practical  problem  of 
facilitating  data  oas'e  access.  Although  a  user  can  oe  impressed 
by  the  sophistication  of  a  natural  language  system,  it  will  pe  of 
ittle  consequence  If  it  requires  riding  roughsnod  over  budgets 
in  order  to  get  one.  Because  of  this  economic  reality,  the 

emphasis  in  AvlT  nas  been  on  simplicity,  wicn  natural  language 
left  to  fit  in  where  possible. 

This  limitation  on  natural  language  power,  tnougn,  turns  out 
to  oe  only  minor  in  the  context  of  the- data  case  access  problem. 
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Tttererce  Is  Ajl',  tor  example,  is  accomplished  through  extremely 
sirple  means*  particularly  in  contrast  with  the  lengths  that  some 
"intell i cent "  natural  language  systems  go  to;  these  simple 
means,  however,  seem  to  he  entirely  vorODle. 

An  Avl  taeility  will  wort  oest  with  data  bases  that  have 
highly  reoular  structures  and  that  deal  with  one  particular 
subject  area.  It  is  designed  tor  selectively  displaying  the 
contents  ot  a  data  base  without  any  automatic  support  of 
inference;  it  is  possible  to  retrieve  information  not  explicitly 
stored  in  a  aata  oase,  nut  this  must  oe  done  by  including  special 
procedures  that  define  virtual  lata  tields  in  effect.  An  AQT 
tacllitv  thus  will  be  most  usetul  In  applications  where  the 
prohlem  is  the  accessiblilty  ot  online  data  and  not  its 
interpretation.  inis  probably  a  reasonable  strategy  given  that 
human  relnns  are  typically  better  at  interpretation  than  machines 
while  finding  difficulty  with  tne  mechanics  of  data  access. 

The  effective  use  ot  an  Agr  facility  will  require  a  certain 
amount  ot  training,  first,,  a  user  must  icnow  in  a  general  way 
what  is  contained  in  a  target  data  oase  because  language 
processing  in  Ayr  geoends  a  great  deal  cn  queries  being 
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doiiialn*restr lct«o,  oecond.  tn«  user  must  also  understand  that  an 
AOT  facility  is  oesicdlly  not  Intelligent;  it  can  only  respond 
directly  to  Queries  and  even  at  this  Kust  ultimately  fail  as 
queries  grow  Increasingly  comoiex.  The  user,  however,  need  not 
oe  familiar  wlti  tne  actual  structure  of  the  target  data  base  or 
with  the  actual  operations  involved  in  query  translation.  The 
data  ease  nanajer  will  require  the  most  training. 

An  Ayr  facility  is  designed  for  easy  installation  and 
maintenance.  Changes  to  a  target  data  base  can  be  accommodated 
in  most  cases  oy  updating  translation  tables.  Extending  a  query 
language  vocanulary  is  a  simple  process;  extending  a  grammar  is 
more  difficult  in  tnat  it  requires  some  expertise  in  linguistics, 
but  this  can  also  be  done  as  a  taole  uoiate.  The  Identltlcation 
ana  correction  of  actual  errors  In  code  is  aided  by  the 
oroanizatlon  of  tne  query  translation  process  into  distinct 
passes  and  by  tne  avoidance  of  complex  algorithms. 

The  eventual  goal  of  AOl  is  to  produce  a  natural  language 
system  that  is  flexible  but  yet  reliable  enough  to  run 
effectively  with  aooilcatlons  In  tne  real  world.  A  persistent 
difficulty  with  natural  language  Is  that  It  still  lacKs 
credibility;  for  despite  its  supposed  advantages,  it  is  still 
hard  to  convince  persons  responsible  for  assembling  practical 
information  systems  that  true  natural  language  access  is  a 
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serious  alternative.  we  want  to  snow  with  AQT  tr>at  natural 
lanquaoe  is  ro  longer  a  nothouse  curiosity,  but  a  basic  tool  to 
solve  real  proolems. 

6.3  Areas  tor  furtner  woric 

Because  tne  AvT  denonstrat ion  system  was  built  primarily  to 
snow  oossiblllties  we  were  concerned  not  so  n.ucn  witn  developing 
specific  asnects  of  tne  system  as  witn  estallsnlng  tne  overall 
concept  of  table-driven  query  translation.  mere  remains  a 
consideraole  amount  of  woric  to  do  for  tne  implementation  of  a 
full  prototyoe  query  facility;  tne  oroolems  involve  both 
ennancements  of  basic  capabilities  already  in  tne  demonstration 
system  and  altogether  new  capabilities  necessary  to  support  true 
natural  language  access. 

The  princloal  enhancements  that  seem  called  for  are; 

o  numerical  comoutatlons  on  fields 

The  demonstration  system  now  computes  sums,  averages, 
maxima,  minima  of  fields  in  a  rudimentary  way.  This 
could  oe  elaborated  further  to  incorporate  more 
statistical  functions  and  to  allow  arithmetic  opera¬ 
tions  on  fields  and  tne  results  of  functions.  One 
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Interestin'!  nossinllity  Is  to  oailo  in  tools  tor 
explor-itorv  oat  ■  -jiijlysls  in  tne  "•^nner  ot  ToKey  IllJ, 
Incluoim  tne  various  oracnical  iiisi/lays  tnai  are  an 
intrinsic  part  ot  Sucn  analysis.  Inere  ire  nany 
tiiii\js  *6  couli  30  iiere;  one  -.njor  oroolen  nere  will 
t-e  tnat  ot  oeci'iino  *nat  is  tost  oporooir  i  ate  tor  a 
General  luery  facHitv. 
o  reterence 

Tte  current  oroceoures  tor  reference  jo  not  ta<e  into 
account  tne  actual  torn  ot  a  aoery?  tnev  note  only  the 
Intersection  of  tne  tieio  soec 1 t ications  tor  tne 
current  ano  prece<Sino  noeries.  Tne  scnene  actually 
worKs  out  quite  <*611,  hut  it  nas  tre  li'^itation  of  not 
correctly  nanalinn  certain  icinds  ot  terse  uuery 
seqviences  xnere  consecutive  qjerles  nave  no  explicit 
ficlo  soecif Ications  in  co'nnon.  It  seens  loore  reason- 
atle  to  extend  tne  reference  oroceoure  nere  rather 
than  slnoiy  to  fornio  sucn  sequences, 
o  cr  apiirar 

if.e  current  Ayr  iranw  ir  consists  of  a  set  ot  rules 
accu  mi late-1  to  test  the  ie'^onstratlon  systein.  There 
are  -lef ic leoc ies  in  nanoiinn  conjunction  an-i  sone 
ruleSf  sucn  tnose  tor  sequences  ot  tielo  nanes.  could 
re  forpulated  netter.  ine  casic  urarTar  viil  nave  to 


re  reworxeo  an-i  extended  for  use  in  a  prototype  querv 
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t-ici  Uty. 

c  irntxiTH)  o-itc'ie'i  r^cor'i  instances 

1ft  r.»  iionstr-ition  svste-!  science  for  retrievin';  record 
irscances  ann  mstiayi.ii  results  is  ade^juate  tor  a 
faU  test  data  oase.  rjt  in  aeneral,  it  *ill  require 
tcc  '■'am  re’i'nry  tor  inoex  lists.  In  tne  protO" 

tyre  query  facilitv,  retrieval  ana  display  of  results 
viil  ftove  to  ne  interleavea,  allo^'  inoex  lists  to  oe 
read  in  am  .rltten  out  increTental ly , 

done  lie*  are  IS  to  ue  explored  incluoe; 

c  neodtion 

.•■ecation  in  aeneral  can  ne  exceedingly  corr.oiex  to  nandle 
in  natural  lamaage,  nut  Pecause  it  is  descriptively 
necessary’  at  ti-nes^  a  guerv  facility  should  accept  it 
at  least  in  a  linited  for’".  inis  will  require  major 
cranies  aloni  tne  entire  process  of  query  translation, 
p  sutstecies  an  i  variants 

It  is  soneti'nes  nelnful  tor  a  logical  data  rase  model  to 
olio*  sumrounind  ot  data  ny  certain  <eys;  for  example, 
in  comontina  a  nean,  *e  moV  want  to  advd  In  a  sinole  value 
fci  a  <ev  sunaroup  instead  ot  taxino  tnem  individually, 
me  Ayi'  strim  pattern  i"atcner  usei  on  ftSCll  Xeys 
addresses  tnis  rroriei’  sonevnat,  but  a  more  general 
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aptrodcn  is  needed, 

0  sorting  and  aroopino  ot  results 

In  the  demonstration  system,  results  are  displayed  strictly 
in  order  ot  retrieval;  nut  It  is  generally  nelpful  tor  a 
user  to  have  output  sorted  or  grouped  oy  various  keys. 

This  could  oe  accomplished  in  a  fairly  straightforward  way 
by  adding  another  oass  to  the  guery  translation  process, 
o  interfaces  with  multiple  data  oases 

because  a  user  sees  data  only  through  a  logical  model, 
it  should  not  matter  how  many  different  data  bases 
that  gata  is  orawn  from.  iwo  possibilities  arise  here: 
we  can  generalize  the  AyT  record  access  procedure  to 
allow  a  single  logical  model  to  refer  to  several  data 
tases,  or  we  could  allow  a  user  to  switch  from  one 
looical  model  to  another. 

8, A  Plans 

Current  plans  tor  AgT  call  tor  the  development  ot  a 
prototype  query  facility  in  KORTHAN.  It  will  be  Implemented 
first  on  a  PEC  pnp-U/70  under  the  RSX-llM  operating  system  and 
then  probahlv  taken  to  a  VAX-n/780  under  VMS  running  in  32-bit 
native  mode.  The  move  should  allow  the  ooptablllty  ot  the  system 
to  be  assessed,  work  in  this  area  is  scheduled  for  completion  in 
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Octooer  of  IVbo. 

As  a  test  of  the  capahlllties  of  the  prototype  query 
facility,  we  will  try  to  get  a  large  data  base  of  current 
interest  tor  an  exoer in'ental  application.  In  setting  the  system 
uo,  we  Plan  to  go  tnrough  ail  tne  formal  procedures  that  an 
actual  data  case  manager  would  go  tnrougn:  identifying  tne 
target  data  to  ne  accessed,  constructing  tne  tables  for  query 
translation,  and  actually  generating  a  load  image  of  the  system 
from  dislricutlon  sources. 

To  the  extent  tnat  it  is  possiole,  we  will  get  actual 
Information  users  to  try  the  system  out,  either  oy  bringing  it  up 
on  a  processor  available  to  the  users  or  by  arranging  for 
communication  from  remote  terminals  over  telepnone  lines.  This 
would  allow  us  to  see  now  natural  the  system  really  is  and  also 
to  let  users  nelp  in  guiding  its  course  of  development.  It  is 
hoped  that  the  relative  ease  of  settino  up  an  AQT  facility  will 
make  potential  users  more  receptive  to  participation  in  such 
testing. 


H.b  Summary 


ine  PhilosophY  behind  AQT  was  that  the  natural  language 
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aspect  ot  the  proolem  was  actually  less  Imoortant  than  tne  data 
base  aspect.  Belnu  able  to  express  queries  in  tne  form  of 
English  Is  of  little  help  if  a  user  cannot  figure  out  what  to  astc 
in  a  given  situation.  So  instead  ot  thinicing  aoout  grammars  and 
dictionaries  first,  we  started  by  consioerinq  now  to  maice  data 
bases  as  transparent  as  possible  so  as  to  maice  access  to  them 
easier. 

The  major  difficulty  presented  oy  data  oases  is  tnat  its 
structure  is  typically  determined  by  purely  tecnnical 
considerations  such  as  minimizing  the  amount  of  storage  used, 
optlmlzlnd  certain  access  paths,  ana  exploiting  storage  devices. 
Because  none  of  this  is  pertinent  to  a  person  who  simply  wants  to 
retrieve  information,  the  trend  has  been  to  ;na<e  tnis  Invisible 
tnrough  imposing  Increasingly  aostract  logical  models  on  top  of 
data  oases.  The  notion  ot  relational  nlerarcnies  comes  from  tnis 
process  of  abstraction  taxen  to  an  extreme:  tne  naming  of  data 
items  as  well  as  their  structure  is  made  Invislole. 

The  use  of  a  relational  nierarcny  as  a  logical  data  model 
suggests  a  simple  and  practical  way  ot  Interoretlng  natural 
language  queries.  Such  queries  are  first  maoped  as  an 
intermediate  step  into  references  to  a  relational  hierarchies; 
these  references  can  then  oe  mappea  into  references  to  a  larger 
data  base  tnrough  translation  tables  describing  tne 
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correspondence  oetween  ^n  interne  iiate  model  and  a  data  base. 
This  approach  ones  not  reodlre  a  large  machine  for  an 
implementation:  In  fact.  It  can  oe  programmed  In  FORTRAN  on  a 
DEC  POP-11/70. 

The  relative  simplicity  of  tne  Ai^f  puts  It  within  reacn  of 
many  infornation  users  for  whom  natural  language  access  may 
otherwise  be  unavailaole.  because  tne  code  tor  AQT  is  In  FORTRAN 
it  shoulG  te  runnable  on  most  machines  large  enough  too  support  a 
data  base  system.  The  AsJT  facility  is  self-contained:  It 
requires  no  additional  software  to  go  with,  and  it  can  as  In  the 
case  of  the  demonstration  system  wor<  directly  on  ordinary  files 
without  a  separate  data  base  management  paclcage. 

An  AvT  facility  is  designed  to  go  out  to  the  user.  Setting 
it  up  is  easy,  and  it  can  readily  evolve  as  a  user  gains 
experience  with  it.  Most  of  tne  wor<  of  tailoring  a  facility  to 
a  target  data  base  will  oe  in  deriving  a  relational  hierarchy  as 
a  logical  mocel  ana  in  constructing  the  translation  tables  to  go 
with  the  model.  Experimentation  witn  the  facility  win  involve 
very  little  rlsic  on  the  oart  of  the  user. 

Tne  development  of  AOX  is  an  attempt  to  ma<e  natural 
language  a  realistic  solution  to  data  base  access  problems. 
Natural  language  is  important  not  only  in  tnat  it  can  expedite 
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certain  tMngs  no*  oeing  none  out  also  in  tnat  it  opens  up 
possioilltles  for  pringlno  tne  ultii'ate  users  of  information 
closer  to  the  sources  of  Information.  natural  language  can  serve 
as  a  coirn.on  access  method  to  many  aitterent  oata  nases  at  tne 
same  time,  maiclno  tneir  aggregate  contents  immediately  availanie 
for  analysis  or  decision  maiclng.  Tne  Ayf  effort  is  only  a  small 
step  in  this  direction,  out  it  is  a  realistic  one  and  should  help 
pave  Che  way  tor  other  systems  yet  to  come. 
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APPEiMDIX  A 

.  A  Session  wlta  the  Demonstration  System 


PUN  AtT 


***  AOT  Dt^'ONSrRAT^UM  SYSTKH  *** 


UMY>TELL  AfiOUT  AIPCRAPT. 

AIRCRAFTC?) 

(.) 

PI  AlPCHAFl 

THIS  IS  A  SOVIET  FIGHTER  AIRCRAFT  DATA  RASE, 
DERIVED  FROM  UVCLASSIFIEP  P'JbUC A TIDnS.  IT 
DESCHIHES  CPF^S,  Fi'SEI.AGES#  ‘'I.vGS,  £,*GIi^ES, 
APMAMFKTS,  AtU)  PERFORMANCE. 


opy>names  of  aircraft / 

AIRCRAFT 

.  AIRCPAFT(?H  MAMEsFJ 

(.) 

NAME 


FIPEBAP  YAK-2RP 

FIDDLER  i''.»-2tJP 

FLAGON -E  SO- IS 

FLAGON-D  SU-IS 

FLAGON-C  SU-I5 

FLAGON*B  SU-15 

FLAGON -A  SU-15 

FLAGOlv  .  SU-15 

FISHPOT-C  SIJ-9 

FlSHPOT  SiI-9 

FOXBAT-S  UG-2S 
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FUXBAT-A 

UG-25 

FOXBAV 

MlG-25 

FL(iGGE:P-C 

HIG-23U 

FLOGGir  P*R 

viIG-2 

FLOGGER 

hIG-23 

ElSiiPE'D-d 

■aG-21RE'f^A 

EISHHEP-r 

■1CG-21PEM 

E'  lSrtHET)”D 

UG-21PF 

FlSriBEIi-I 

.nIG-21  ’■iF 

FISHHFL— N 

4IG-21HF 

FISriBt  D-0 

.'»IG-21mF 

EISHht.r-C 

UG-21F 

FISmBEC 

MlG-il 

FAPyEri-C 

1IG-1HSE' 

farmep-l 

.UG-IH?.', 

FARHrJP-D 

UG-19PE' 

FAPMEh 

v.IG-19 

fhe:scc- 

MIG-1  7 

gki>AhAT  IS  Ttifi  iJArO  MA:<E  OF  THE  KlG-19  AND  iitrtEN  DID  IT  ENTER 
SERVlCt? 

AlRCKAFi 111) ISERV ICE  MAM£sHiG-19) 

.  AlHOPAET( ?) (<<NATO>>  NAHEa*) 

C.) 

<<NA1U>>  CAEE 


FARMER  HIG-19 

.  AIKCRAH 

.  AIRCPAFTC  ?)  C^HKH  IT  ENTERED  «SEKVrce»  =  ») 

(.) 

AriEN  IT  ElvTEPEU  «SERVICE» 


1955  hIG-19  FARMER 


QRy>».RAT  IS  THE  AVERAGE  LENGTH  OF  AIRCRAFT  WITH  A  WING  SPAN 
GREATER  THAN  25? 

aircraft 

.  DImFNSIOM  ?)(  (AVERAGED  LENGTHS*  J 
.  V’lNG  DIMENSION  [SPAN>25J 
(.  } 


LENGTH 


A,  A  session  with  the  De>nonstraclon  s/utem 
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YAK-2bP 

FtWKAAP 

71.04 

TU-28P 

FlOL»LH:i< 

85.00 

SU-lh 

FLAGLiM-E 

«>8.00 

SU-J5 

FLAGUN-u 

hS.OO 

SU-15 

FLAGOM-C 

O'R.OO 

SU-15 

FIjAGO  't-ti 

68.00 

SU-15 

FGAGiJN-A 

68.00 

SlJ-15 

Fl(AG>Ji'< 

68.00 

SO -9 

FiSHPOr-C 

55.00 

SO-9 

FiSHPnr 

55.00 

MlG-25 

FOXUAl-B 

o9.00 

MlG-25 

FJXBAf-A 

69.00 

NllG-25 

F'lX  SAT 

69.00 

VIG-230 

FLOGGEF-C 

55.13 

-lG-236 

FLOGGFK-U 

55.13 

MlG-23 

FL.MGGEU 

55.13 

»^IG-195F 

FAAMER-C 

48. RR 

MIG-19FK 

FAPMFR-0 

48.88 

MIG-19PF 

FA.<  3Eh-L) 

48.88 

MlG-19 

Farmer 

48.88 

’nG-17 

FRESCO 

36.33 

AVK.  LhrGlhs  h0.»7 


OHy>Ci.  hUGOHAriCllJS  of  IHE  ^IG«'/IKF? 

AJKCKAMlSEhVlCE  <AMEs:^IG-2lMFl 
.  ABMAMEhT  C»t-4FIGUPAT10i<(?) 

(.} 


^iG-21Mf 


WJG-2IWF 


FISHHED-G  eCFGN* 

*CFGN* 

♦CFGh* 

♦CFGN* 

F16HtJEi)-K  ♦CFG-'I? 

♦CFGN* 

*CKGNe 


2 

UN 

BOMS 

UKN 

2 

UN 

BOMB 

UKN 

4 

AS 

ROCKET 

UKN 

1 

UN 

cannon 

UKN 

2 

AA 

MISSILE 

ATOLL 

1 

UN 

cannon 

UKN 

2 

AS 

ROCKET 

UKN 

2 

AA 

MISSILE 

ATOLL 

1 

UN 

cannon 

UKN 

4 

AA 

MISSILE 

ATOLL 

1 

UN 

cannon 

UKN 

2 

UN 

BOMB 

UKN 

2 

UN 

BOMB 

UKN 

4 

AS 

ROCKET 

UKN 

1 

UN 

cannon 

UKN 

2 

AA 

MISSILE 

ATOLL 

1 

UN 

cannon 

UKN 

2 

AvS 

ROCKET 

UKN 

Page  A-4 


A. 


A  Session  with  the  Demonstration  System 


2 

AA 

MISSILE 

ATOLL 

1 

UA) 

CANNON 

UKw 

♦CFGn* 

4 

AA 

MISSILE 

ATOLL 

1 

UR 

CAkRON 

UKR 

FISH3E0-J  eCEGN* 

2 

UR 

BOMB 

JKR 

2 

UR 

BOMB 

UKW 

4 

AS 

ROCKET 

UKR 

1 

UR 

CANNON 

UKR 

♦CFGN* 

2 

AA 

MISSILE 

ATOLL 

1 

IJR 

CANNON 

UKw  • 

*CFGN* 

2 

AS 

ROCKET 

UKR 

2 

AA 

MISSILE 

ATOLL 

1 

□  R 

C ANnOn 

UKR 

♦CFO*^* 

4 

AA 

MISSILE 

ATOLL 

1 

UR 

CANNON 

UKN 

QKY>»iHAT  IS  THE  COMBAT  RADIUS  uF  SOVIET  AIRCRAFT  CARRYI’^G  ATOLl? 


AIRCRAFT  APMAMEmT  CUf^FIGURATIO:.!  wFAPOM  ( V  a'TO  A'A^EsATOLD) 
.  PERFORMANCEC?) (1 1) C<<C0h8AX>>  RADIUSs*] 

(.) 


«COMRAT>>  KAO  HIS 


MIG-21PFMA 

FISriHED-J 

11B3 

MIG-2 IPKM 

FISHHED-F 

1183 

MIG-21 MF 

FISHBED-L 

U83 

MIG-21 MF 

FISHBEU-K 

1183 

MIG-21MF 

FISHBED-J 

1183 

MIG-21F 

FISHBED-C 

1183 

ORY>OC  ANY 

AIRCRAFT  CARRY 

THE  ACRID  MISSILE? 

AIRCKAFT(Y/N?) 

.  ARMA»iENT 

configuration 

WEAPONdl  j  cclasssmissile.nato 

NAME*ACRIDI 

(.) 


YES. 

FULL  OUTPUT? 
NO 


ORY>HOW  MANY? 

.  AIRCRAFT!#?) 

(.) 


km  k  Session  wltn  the  Demonstration  System 


AIRCRAFT(S) 
COUNT  =  1 

FULL  OUTPUT? 
YES 


rtIG-25 


KOXUAX-A 


ORY>ITS  SPEED? 

.  PERECR«AfiCE(  ?  j  (  1  i  J  [SPEED«*) 

(.) 


SPEKO 


MIG-25 


FOXBAT-A 


100000 
90000 
80  000 
70000 
60000 
50000 
40000 
30000 
20000 
lOOOO 
0 
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QRY>WriAT  IS  THE  MINIMll.M  LENGTH  OF  INTERCEPTORS? 

AIBCRAFT[ROI.E.=  tA»<|  URU 
.  OIMENSION(?)(l!)  [(•4.IMMUN) 

(.) 


MIN  LENGTMsAlfil 


SU-15 


LENGTH 


FLAGON-E 


68 .00 


0RY>OF  POMbEPS? 

.  AIRCRAFTIK(iLE={F/)Bl 

(.} 


MIN  LENGThsF/U 


mIG-17 


LENGTH 


FRESCO 


36.33 
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Dtiy>PLt.ASf.  DKSCKIrtE  CHEWS. 

AIKCKAFT  CREw(?l 

(.) 

e4  CHE* 

OfjHf  CREW  5I7E3  ARE  KnOwa.. 


(jRy>Hni»  vAi.i  aikchae't  carry  i  cre'wmeu? 

AIRCRAF 
.  CPF>[if=2] 

(.) 


AIKCRAET(S) 
COUNT  =  4 

EULL  riUTPDl? 
YES 


viG-25 

MIG-Jb 

MIG-25 

:'11G-231' 


POXbAT-B 

FOXriA'f-A 

POXhAt 

FG06GER-C 


ORY>HOW  mANY  CARRY  I? 

,  AIRCPAFK*?) 

.  CREi»l»  =  l] 

(.) 


I 

I 


AJRCRAFT(S) 
COUNT  =  25 

FULL  OUTPUT? 
NO 


UKY>.. 


♦**  END  AOl  *** 
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Transl^tlori  Tai-les  tor  Soviet  Mrcraft  Data 


PKI.ATlf'K  ^A^^:  TAHI-f 


N  Aht 

HECOKD 

tYPE 

ANCESTOH 

10 

LINKAGE 

AII^CHAKT 

1 

0 

l-l 

AMKA-'Kt-  T 

3 

1 

1-1 

CQNFIGU*»AlinN 

4 

2 

1-M 

CPf> 

1 

1 

l-l 

1 

I 

l-l 

DlNENSTOf; 

1 

9 

l-l 

OlyENSION 

1 

IS 

l-l 

EA'GINK 

1 

1 

l-l 

FUSEGAGfc 

1 

1 

1-1 

IDE.MTlFICATItiM 

1 

1 

l-l 

lOEf’TIFlCATlU'/ 

1 

» 

l-l 

PtHFO»«^ANCi:. 

i 

1 

l-l 

WEAPON 

4 

3 

1-M 

1 

1 

l-l 

WING 

1 

1 

1-1 
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FIELD  CO^FKS^^DfIDE^Ct  TABLK 

RELrt 


SERVICE  MAM  1 
(VATO  IkAME  1 
CHEIm  4 
MANuFACTUFEP  1 
ROLE  1 
FIRST  ELIGH1  1 
when  ITt  ElRSrl  ENfEREiJ 

SERVICE  1 
LENGTH  6 
HEIGHT  h 
CLASS  13 
ACCOMRODAllON  4 
SPAN!  SWEPT]  7 
AFTERBIIRKEK  8 
POWER  8 
MANHFACTURtP  11 

type  11 

COMBAT  RADII'S  12 
SPEED!  VS  AL.ITUOEJ  12 
SIZE  13 
EMPTY  WEIGHT  14 
GROSS  WEIGHT  14 
EXTENDED  WUGHT  14 
EMPTY  ..  14 
GROSS  , .  14 
EXTENDED  ..  14 
TYPE  13 
MFG  DFS  13 
NATO  NAME  13 
ROCKET /POD  13 
MFG  13 
NAME  1 
WEIGHT  14 
. .  14 
»  13 
«  8 
*  4 
LENGTH  S 
HEIGHT  S 
SERVICE  ALTITUDE  12 
ALTITUDE  12 
POWER  RATING  11 
combat  RADII'S  12 


KEC 

TYPE 

DATA 

TYPE 

El  ELD 
OFFSET 

U  E  N  G  T  li 

1 

A 

0 

12 

1 

A 

12 

12 

1 

I 

82 

2 

1 

A 

Pd 

12 

1 

A 

100 

K 

1 

A 

108 

10 

1 

A 

120 

lu 

1 

H 

32 

4 

1 

R 

36 

4 

4 

A 

0 

8 

1 

1 

84 

2 

1 

R 

24 

4 

1 

A 

68 

1 

1 

[ 

64 

2 

1 

A 

48 

16 

1 

A 

44 

4 

1 

I 

144 

2 

2 

R 

0 

4 

4 

I 

48 

2 

1 

1 

7  2 

4 

1 

I 

76 

1 

1 

I 

80 

4 

1 

I 

72 

4 

1 

1 

76 

4 

1 

I 

bO 

4 

4 

A 

44 

2 

4 

A 

36 

8 

4 

A 

8 

12 

4 

I 

52 

2 

4 

A 

20 

1  6 

1 

A 

12 

12 

1 

I 

76 

4 

1 

I 

76 

4 

4 

f 

4 

2 

1 

I 

40 

2 

1 

I 

84 

2 

1 

R 

32 

4 

1 

P 

36 

4 

1 

1 

140 

4 

2 

1 

-4 

4 

1 

t 

6  4 

2 

1 

I 

1  44 

2 
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•  INlfcP-RElATIO.JAL  WECURD  LlfiKS 
TO  I  FHOV'  I  I.I^K  OI'iK 
COOROI  cnOFDl  TYPE  F  lEIiD 


1 

1 

0 

0 

m  m 

0 

ij 

t  TOP-LEVEL  IMDICATOR 

1 

4 

1 

1 

-- 

0 

0 

;  AIRCPAET  TO  CREi4 

i 

5 

1 

1 

0 

0 

;  AIRCRAFT  TO  DIrtEMSIQN 

1 

n 

1 

1 

-- 

0 

0 

;  AIRCRAFT  TO  EMGINE 

1 

9 

1 

1 

»  m 

0 

0 

AIRCRAFT  TO  FUSELAGE 

1 

10 

1 

1 

-- 

0 

0 

AIRCRAFT  TO  IDENTIFICATION 

1 

14 

1 

1 

m  m 

0 

0 

AIRCRAFT  TO  WEIGHT 

1 

15 

1 

1 

m  m 

0 

0 

AIRCRAFT  TO  -tlNG 

1 

6 

1 

9 

m  « 

0 

■J 

FUSELAGE  TO  DIMENSION 

1 

7 

1 

15 

m  « 

0 

0 

WING  TO  DIMENSION 

1 

11 

1 

e 

•  • 

0 

0 

ENGINE  TO  IDENTIFICATION 

1 

12 

1 

1 

«  m 

0 

0 

AIRCRAFT  TO  PERFORM. (RECTYPal ) 

2 

12 

1 

1 

ZZ 

152 

2 

AIRCRAFT  TO  PERFORMANCE 

3 

13 

3 

3 

YY 

0 

2 

CONFIGURATION  TO  WEAPON 

3 

3 

3 

2 

XX 

4 

2 

ARMAMENT  TO  CONFIGURATION 

3 

2 

1 

1 

«- 

14« 

2 

AIRCRAFT  TO  ARMAMENT 

4 

3 

3 

101 

rt- 

0 

7 

CONFIGURATION  ELEMENT  TO  WEAPON 

3 

101 

3 

100 

YY 

0 

2 

COtlFIGURATION  TO  ELEMENTS 

3 

100 

3 

2 

XX 

4 

7. 

ARMAMENT  TO  CONFIGURATION 

♦  I 

NTRA 

• 

KEPATIO 

« All 

RECOHD 

LIiMKS 

4 

13 

3 

0 

0 

7 

;  wEAPOM  CO'JMT  TO  WEAPON 

CCOOKUl^ATE  FAIK  =  PECOPD  TYPE  ♦  HELATION) 


*  RKCOM'  TYPE  ACCESS  TAHLE 


ACCESS 

SIZfc, 

PILE  NAME 

TYPE 

D 

20C 

ok; AQT.DAT 

• 

r 

MAIN  AIRCRAFT  RECORDS 

D 

50 

OK: ALISP.DAT 

e 

SPEED  VS  ALTITUDE  TAbLES 

D 

12 

DK;AR>Ii3AS.NDX 

« 

9 

ARMAMENTS  INDEX  (WITH  COUNTS) 

D 

b4 

DK; APMBAS.DAT 

• 

9 

ARMAMENTS  RECORDS 

Translation  Tables  for  Soviet  Aircraft  Oata 


♦  MANDATOPT  FIELDS  TABLE  FOB  OdTPUT 
COORD  FIELD  DATA 
REO'D  TYPE 


1 

1 

0 

12 

A 

a 

* 

ALvKAYS 

print 

OUT  SERVICE  NAME 

1 

1 

12 

12 

A 

t 

AND 

NATO  NAME  FOR  AIRCRAFT 

4 

13 

8 

12 

A 

a 

» 

IDENTIFY  WEAPON  BY  NATO  NAME 

4 

13 

44 

2 

A 

; 

WF>APON 

TYPE 

4 

13 

0 

8 

A 

; 

WEAPON 

CLASS 

2 

12 

-4 

4 

L 

; 

altitude  .uth 

SPEED 

1 

8 

44 

4 

A 

a 

# 

ENGINE 

TYPE 

1 

11 

44 

4 

A 

a 

0 

(  " 

) 

3 

100 

-1 

6 

A 

} 

CONFIGURATION 

MARKERS 

3 

101 

4 

2 

1 

a 

# 

WEAPON 

COUNT 

(CONFIGURATION) 

4 

3 

44 

2 

A 

a 

$ 

WEAPON 

TYPE 

(CONFIGURATION) 

4 

3 

0 

8 

A 

: 

WEAPON 

CLASS 

(CONFIGURATION) 

4 

3 

8 

12 

A 

a 

0 

WEAPON 

NATO  name 

(COORDINATE  PAIR  =  PECOBD  TYPE  +  RELATION) 


i 


MISSION 

of 

Rome  Air  Development  Center 

MjC  ptoM  and  execitCw  xtizoAxih,  d&vUopmtnt,  tiAt  and 
aUoc^  a&quli^on  pnagacm  in  oi  Command,  Coniaol 

CommnoMtLonA  and  JnteUigenca  iCh]  ajUioitiu,  Tz&hnicaZ 
Ofid  vn^ijMXAXjnQ  AupponX  utUhin  ama6  oi  teitihni&al  compUmie. 
u  pnovAded  to  ESP  P/tognam  OUiaeA  (POi)  and  othzA.  ESP 
The.  ptcncipat  tecnnicat  mcnion  aneao  ant 
e/mmtUcationA,  ttectnomagmtic  guidanct  and  contnot,  iun- 
^^it^nct  0^  gnound  and  aeAOApact  objects,  inttCiigtnct  data 
cotCectcon  and  handling,  in£oAmation  iyotem  ttchnology, 
ionoAphenic.  pnopagatton,  4olid  otatt  icitnczA,  mic/ioioavt 
phyUcA  and  electronic  neliabilittf,  maintainabilitu  and 
compatibility. 


